Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Spiele Programmierer
Establishment
Beiträge: 426
Registriert: 23.01.2013, 15:55

Re: Jammer-Thread

Beitrag von Spiele Programmierer »

Krishty hat geschrieben: 08.06.2020, 16:20Ja, braucht man tatsächlich. Darum gibt es z. B. std::chrono::time_point und std::chrono::duration. Für sowas möchte man übrigens auch oft unterschiedliche Datentypen, weil bei Geschwindigkeiten Gleitkommazahlen ganz gut funktionieren und bei Positionen Festkommazahlen, aber nicht umgekehrt.
Ja da hast du recht. Fragt sich allerdings ob es hier die richtige Wahl ist immer gleich eigene, abstrakte Vektor-Typen einzurichten anstatt halt situationsabhängig die entsprechenden komponentenweise Festkomma- bzw. Gleitkommazahlen zu verwenden (ggf. mit typedef).
So gesehen habe ich sogar auch ein Projekt mit gänzlich eigenen Positionstyp, der als Festkommazahlen gespeichert ist um mehr Genauigkeit rauszuholen und nicht positionsabhängig zu sein. Ein eigener Typ war in diesem Fall notwendig, weil die Spieltopologie ggf. ein Torus ist und man die Koordinaten der Position auf 0 umschlagen lassen muss, wenn man die Weltgrenzen erreicht.
Diese Spezialtypen sehe ich aber eher als notwendiges Übel. Wenn es ohne ginge, würde ich liebend gerne zurück zum normalen Standard-Vektortyp und im GUI und Leveleditor ist alles Vec<float> bzw. Vec<double>.
Krishty hat geschrieben: 08.06.2020, 16:20Mir fallen auch gute Gründe ein, einen Zeiger zu int zu konvertieren, aber geben wir dafür das Typsystem auf?! Mittel ist bei mir übrigens in der Position drin, und wird nicht jedes Mal neu implementiert.
Die Frage ist halt ob man oft genug von der Abstraktion profitiert damit es sich rentiert. Wenn man genügend oft um die Abstraktion herumarbeitet sinkt der Nutzen bzw. verkehrt sich in ein großes Ärgernis.
Zuletzt geändert von Spiele Programmierer am 08.06.2020, 19:02, insgesamt 1-mal geändert.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Spiele Programmierer hat geschrieben: 08.06.2020, 17:24So gesehen habe ich sogar auch ein Projekt mit gänzlich eigenen Positionstyp, der als Festkommazahlen gespeichert ist um mehr Genauigkeit rauszuholen und nicht positionsabhängig zu sein. Ein eigener Typ war in diesem Fall notwendig, weil die Spieltopologie ggf. ein Torus ist und man die Koordinaten der Position auf 0 umschlagen lassen müssen, wenn man die Weltgrenzen erreicht.
Diese Spezialtypen sehe ich aber eher als notwendiges Übel. Wenn es ohne ginge, würde ich liebend gerne zurück zum normalen Standard-Vektortyp und im GUI und Leveleditor ist alles Vec<float> bzw. Vec<double>.
Ja; in meinem Flugsimulator probe ich nun auch schon den vierten Anlauf für Weltkoordinaten (3×float -> 3×int -> 2×48-Bit-Int + 1×32-Bit-Int -> Kugelkoordinaten) und habe die Schnauze mittlerweile derart voll, dass ich wohl alles auf 3×double umstellen werde. Dann ist Ruhe in der Kiste …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Jonathan
Establishment
Beiträge: 2353
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Jonathan »

Also ich muss sagen, mir gefällt die Diskussion. Nicht, weil ich jetzt komplett überzeugt wäre, ich denke immer noch das benannte Parameter ein sinnvolles Sprachfeature wären (insbesondere unter dem Gesichtspunkt, dass sie halt keine direkten Nachteile haben). Aber es ist auf jeden Fall interessant zu sehen, wie man solche Probleme noch angehen kann und was man daraus lernen kann. Wobei natürlich benannte Parameter und unterschiedlich getypte Parameter nicht 'das selbe Problem lösen', aber halt doch Überschneidungen haben. Und ohne das erste hätten wir jetzt auch nicht über das zweite gesprochen.
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Jammer-Thread

Beitrag von Chromanoid »

Jonathan hat geschrieben: 08.06.2020, 23:21Nicht, weil ich jetzt komplett überzeugt wäre, ich denke immer noch das benannte Parameter ein sinnvolles Sprachfeature wären (insbesondere unter dem Gesichtspunkt, dass sie halt keine direkten Nachteile haben).
Das sehe ich anders, Sprach-Features sind brandgefährlich. Ich glaube C++ ist da ein gutes Beispiel :D. Wie ich erwähnte, führt das IMO bei der Anzahl der Parameter schnell zu unangenehmen Auswüchsen. Die schlimmste Falle ist dann, wenn diese lange Liste an Parametern eben nicht in ein Struct o.Ä. refactor't wird, sondern Teile oder die ganze Liste hin- und herkopiert wird. Das macht den Code wiederum schlechter wartbar. Da finde ich die designated Initializers eine viel bessere Idee. Das stupst den Entwickler gleich in eine langfristig vermutlich bessere™ Lösung.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Ooooh fucking Fuck

Meine Debug-Builds enthalten einen Leak-Detector, der pro Leak einen Call Stack samt Quelldateinamen ausgibt. Er hält sich an die Visual Studio-Standards – ich kann dann einfach ins Ausgabefenster doppelklicken, und das bringt mich zu dem Quelltext, der mit dem Speicherleck zu tun hatte.

Das lief zehn Jahre, aber irgendwann in den letzten Monaten hat das aufgehört, zu funktionieren. Erst sporadisch, dann komplett.

Ich habe eben vier Stunden gesucht und finde den Fehler nicht. Ich habe aber ganz geile Dinge gelernt, for fucks sake.

Aaaalso. Microsoft verteilt eine DbgHelp.dll mit der Debug-Help-API. Falls ihr irgendein Programm debuggen wollt, ruft ihr SymInitialize() auf und habt dann so tolle Funktionen wie SymFromAddress() (gib mir zu einer Adresse den Namen der Funktion/Variable, die dort liegt) und SymGetLineFromAddress() (gib mir zu der Adresse einer Funktion/Variable die Quelldatei und Zeile).

Das funktioniert natürlich nur, falls ihr auch die PDB-Dateien dazu habt. Aber ein Symbol Server ist integriert; ihr könnt sie also für Windows-Code on-the-fly von den Microsoft Symbol Servers beziehen und für eigene Programme kompiliert ihr sowieso immer mit PDB.

So weit die Theorie. Die Praxis ist ein Debakel.

Die API ist eine Karikatur aus 16-Bit-ANSI-Code, der durch ein Sammelsurium aus #defines und Typen wie DWORD64 irgendwie in die 64-Bit-Ära gehievt wurde. Die komplette Bibliothek ist single-threaded und verlangt, dass ihr selber darauf achtet, sie nie aus zwei Threads zugleich zu nutzen. Die Dokumentation ist voller Blüten wie
Parameter: hProcess
A handle that identifies the caller. This value should be unique and nonzero, but need not be a process handle. However, if you do use a process handle, be sure to use the correct handle. […]
Sowas hat mich noch nie abgeschreckt; ich wrappe sowas weg und nutze die Vorteile.

Dann kam Visual Studio 2017. Weil 75 % der Linker-Zeit für das Schreiben der Debug-Informationen draufgingen, haben sie FASTLINK eingeführt. Damit wird der Linker viel schneller, aber es ist ein Breaking Change im Dateiformat.

Ihr ahnt, was jetzt kommt.

Die DbgHelp.dll, die mit Windows kommt, kann das neue Dateiformat nicht. Sie verweigert den Dienst oder crasht den Prozess(!). Sie haben FASTLINK als Standard eingeführt; überall hat also die Debug-Help-API mit Visual Studio also aufgehört, ordentlich zu funktionieren. Oh fucking Fuckers. For fucks sake fire them all.

Die „Lösung“ ist, dass man die Debugging Tools for Windows installiert und deren DbgHelp.dll nutzt. Nun kann man die Debugging Tools aber nicht einfach irgendwo runterladen. Man bekommt sie als Teil des Windows-SDKs oder des Driver Development Kits. WARUM KEIN SCHEIß WINDOWS-UPDATE?!

Weil Windows dann nicht weiß, welche DbgHelp.dll die richtige ist, müsst ihr die DLL (und alle ihre Abhängigkeiten, because FUCK YOU) in das Verzeichnis kopieren, in dem man seine Anwendung debuggt. Ehrlich: https://docs.microsoft.com/en-us/window ... p-versions

Aber wartet! Irgendwann letztes Jahr haben sie sich gedacht: Lass uns doch mal den Pfad ändern! Die Dokumentation schwafelt von Program Files\Debugging Tools for Windows, aber in Wirklichkeit liegt die Grütze nun unter C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\srcsrv. WEIL DAS JA KLAR IST.

Und dann sollte alles funktionieren. Tut es aber nicht; alle meine Aufrufe geben ERROR_INVALID_ADDRESS zurück. Und ich bin verdammt nochmal nicht der einzige. Entweder gibt es keine Lösung, oder jeder findet eine andere, immer skurrilere.

Das ist so ein typischer Fall von you can’t just XXX.
Nein, man kann nicht einfach eine PDB laden und einen Wert daraus abfragen.
Nein, man kann nicht einfach eine DLL benutzen, die Windows beiliegt.
Nein, man kann nicht einfach die Debugging Tools for Windows herunterladen.
Nein, man kann nicht einfach ganz am Anfang der Dokumentation nachlesen, dass die Scheiße sowieso nicht funktioniert und die Benutzung so angenehm ist wie das Lecken von Busfahrerärschen.

Oh wartet! Es gibt noch eine zweite API. Die DIA-API erlaubt, PDBs zu laden und Daten daraus zu lesen. Und jetzt ratet mal, wie man die benutzt …

Na, ganz klar: Jedes Mal, wenn eine neue Visual Studio-Version rauskommt, ändern sich Name der DLL und UID der Schnittstelle. Auszug aus dem Sizer von Aras Pranckevicius und Fabian ryg Giesen:

Code: Alles auswählen

	static const struct DLLDesc
	{
		const char *Filename;
		IID UseCLSID;
	} DLLs[] = {
		"msdia71.dll", __uuidof(DiaSource71),
		"msdia80.dll", __uuidof(DiaSource80),
		"msdia90.dll", __uuidof(DiaSource90),
		"msdia100.dll", __uuidof(DiaSource100),
		"msdia110.dll", __uuidof(DiaSource110),
		"msdia120.dll", __uuidof(DiaSource120),
		"msdia140.dll", __uuidof(DiaSource140),
		// add more here as new versions appear (as long as they're backwards-compatible)
		0
	};
Oh, das ist ja GANZ GENAU die Art von Code, die ich in meinem Projekt warten möchte. WER HAT DEN LEUTEN, DIE DIESE DEBUGGING-APIS MACHEN, EIGENTLICH INS HIRN GESCHISSEN?!

Wie macht Visual Studio das eigentlich?! Bei WinDbg weiß ich, dass es ebenfalls Debug Help benutzt und deshalb mit FASTLINK-Programmen ständig abstürzt oder nichts anzeigt. Aber Visual Studio?! Oh ich will’s wahrscheinlich gar nicht wissen.

Ich möchte echt nur einen Call Stack nach Text mit Zeilennummern konvertieren, und jetzt bin ich kurz vor’m Nervenzusammenbruch.

Nachtrag: BWAHAHAHA fuck my life

Wenn in der EXE ein absoluter Pfad zur PDB steht, wie C:\Users\Krishty\fuck_this_shit.pdb, dann funktioniert es. Wenn einfach nur fuck_this_shit.pdb drin steht, schlägt es fehl, obwohl alles im selben Verzeichnis liegt.

Oh, und Visual Studio zeigt gar nicht alle Compiler-Optionen an, wenn ihr in den Projektoptionen auf Command Line geht. Vererbte Optionen werden teilweise versteckt, sonst hätte ich das im Vergleich mit einem funktionierenden Projekt schon viel früher gefunden. Nein nein, weil die Schwanzköppe da wahllos Parameter ein- und ausblenden, musste ich Executables diffen wie in der Steinzeit. Fuck em, das gibt einen Bug Report.

Nachtrag 2: Bug Report für den UI-Schrott: https://developercommunity.visualstudio ... rojec.html
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Das Kompilieren von vier HLSL-Shadern dauert in Visual Studio so lange wie 100 C++-Dateien.

Ursache ist wohl nicht, dass der HLSL-Compiler langsam ist, sondern dass Visual Studio seriell kompiliert – elf Kerne schlafen, während ein Shader nach dem anderen durchgekaut wird.

Ich bin mir erst 90 % sicher; muss dafür einen Repro schreiben und ggf. einen Bug melden.

Gruselig, dass Multithreading in MSBuild eine sprachabhängige Einstellung zu sein scheint. Stellt euch mal vor, make oder ninja wäre nur für C++-Quelldateien parallel …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Wenn du dir einen neuen PC kaufst, über Monate sporadisch Kernel-Abstürze hast, und dann merkst, dass Ryzen-CPUs inkompatibel mit dem Nvidia-Treiber sind (https://forums.tomshardware.com/threads ... a.3594431/) … aaaalso wieder eine AMD-GPU her, WTF
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

Ich habe exakt diese Kombo seit 2 Monaten am Laufen und noch keinen Bluescreen. Bist Du sicher, dass Du diesem Forenthread trauen kannst?

[edit] Könnte aber auch daran liegen, dass ich ne 1070 eingebaut habe und der Fehler laut Fließtext mit der 2000-Generation sehr viel häufiger auftritt.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Ich weiß nicht; sind diese Foren unzuverlässig?

Da melden hunderte Leute das gleiche Fehlerbild, über mehrere Monate. Die Posts lesen sich wirklich schmerzvoll, und die Symptome sind wirklich genau meine. (Seit einem BIOS-Update im MärzApril. Davor waren es random Reboots ohne Kernel-Dump.)

Die angeblichen Erklärungen von AMD & Nvidia klingen mindenstens falsch wiedergegeben oder komplett erfunden, ja. Sicher sind auch Leute mit Intel-CPUs dazwischen, aber das betrachte ich als übliches Rauschen.

Wenn man durchscrollt, ist Ryzen + Nvidia tatsächlich das deutlichste Merkmal. Warum das nicht bei jedem Ryzen-Nvidia-System auftritt? Ich weiß nicht. Es sind augenscheinlich vor allem Leute betroffen, die sich mit GPU-Treibern und BIOS-Updates auskennen. Das könnte daran liegen, dass Wissen um GPU-Treiber und Event Viewer Grundvoraussetzung ist, diese Threads überhaupt zu finden. Oder aber an einer faulen BIOS-Version oder -Einstellung.

Nachtrag: Oh wow, jetzt habe ich erstmal gelernt, dass AGESA 1.0.0._ das BIOS ist, die ich von MSI nur als 7B86vM_ kenne.

Nachtrag 2: Cool, vor ein paar Tagen kam ein neues BIOS-Update raus. (Natürlich direkt nach dem Windows-Patchday, damit ich’s verpasse.) Improve graphics card compatibility; Improve memory compatibility; Improve audio card compatibility. Dann mal los …

Nachtrag 3: MSI BIOS-Updates-Anleitung, ganz oben:
https://www.msi.com/files/pdf/How_to_flash_the_BIOS.pdf hat geschrieben:WARNING!!!!!
DON'T FLASH WHEN YOUR SYSTEM IS RUNNING FINE!!!!
NA DAS SCHAFFT JA VERTRAUEN!

Nachtrag 4: Das BIOS hat sich nur ein einziges Mal aufgehängt vor dem Flashen. LIEF ALSO SUPER. In einem Monat weiß ich, ob’s was gebracht hat.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Es war ja nur eine Frage der Zeit, bis PowerShell Werbung einblenden würde

Bild

Boah, der Tag kann nur besser werden
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Ich habe dazu leider auch mehrere Datenpunkte:

1) Es gibt hier im Haushalt ein Lenovo / AMD Laptop das ab Kauf regelmäßig BSOD hatte. Ich bin mir nicht mehr ganz sicher welchen, ich denke es war DRIVER_IRQL_NOT_LESS_OR_EQAL oder VIDEO_SCHEDULER_INTERNAL_ERROR oder mal der eine und dann der andere. Reines AMD System wohlgemerkt. Ein Treiberupdate war nicht möglich da dies ein BIOS-Update erforderlich machen würde und Lenovo es hinbekommen hat dass diese Spezielle Baureihe bricked wenn man das BIOS updated.

Der Workaround laut Internet war dann die Hardwarebeschleunigung im Browser abzuschalten, was auch tatsächlich einiges gebracht hat. U. a. deshalb weil Browser ja heutzutage 90% der Gerätenutzung ausmachen.

Die Bluesceens sind dann irgendwann ohne weiteres zutun ganz verschwunden, ich habe ein Windows-Update im Verdacht, dass um den Scheiß-AMD-Treiber drumrum arbeitet. Der Schurke in der Geschichte ist aber natürlich trotzdem irgendwie Lenovo ohne die wir nicht an dem Treiber festhängen würden.

Das Gerät hat immernoch massive Probleme in manchen W-Lans (ich vermute es kommt auf die Klasse des W-Lans an) was wie man gleich sehen wird möglicherweise relevant sein könnte.

Alles im allen ist es halt ein Consumer Grade Laptop, da erwarte ich Herstellerunabhängig dass es beschissen ist und so richtig hatte keiner Lust sich mit dem Support rumzuschlagen. Mit den Business Lenovos (aka ThinkPad) habe ich deutlich bessere Erfahrung gemacht. Das dann allerdings auf Intel.

2) Ich bin jahrelang (2 Systeme ~10 Jahre, AMD GPUs hießen glaube ich noch ATI) Intel + Nvidia gefahren. Ich hatte immer Vorurteile gegenüber AMD. Beim letzten Update habe ich trotz 1) auf Ryzen gesetzt (vor allem habe ich logicalincrements vertraut, vielleicht ein Fehler) dann aber u. a. wegen 1) und auch weil ich wahrscheinlich unbewusst nicht alles auf AMD setzen wollte (laut deinem Link wahrscheinlich auch ein Fehler) eine Nvidia GPU.

BIOS hatte ich bei der Installation upgedated (ich glaube das Mainboard ist von Gigabyte, falls relevant), ich hatte sofort das Gefühl dass das System dadurch schlechter lief, aber da ich es da gerade neu hatte habe ich es nicht lange mit dem alten BIOS erlebt, also wer weiß.

Außerdem hatte ich (aus Gründen) gemeinsam mit dem System einen alten WiFi Stick in Betrieb genommen für den es nur Windows 8 Treiber gab, die Windows 10 aber akzeptiert hat (da ist die Connection zu WiFi oben, kommt noch mehr).

Ich hatte am Anfang im Betrieb genau die Bluesceens aus 1)

Außerdem hatte ich oft gefühlt mehrere Minuten Blackscreen und dann ging es weiter.

Interessanter Weise nicht in Spielen, wo die GPU mal gefordert wäre sondern, so stellte ich ziemlich schnell fest, wenn im Hintergrund Netzwerktraffic aus dem Browser war (z. B. Youtube oder noch eklatanter wenn du bei Facebook scrollst und es läd im Hintergrund schonmal das Video) Irgendwann habe ich es dann geschafft kurz vor oder nach dem Blackscreen tatsächlich mal in den Task-Manager zu kommen, und hatte horrende Auslastung in Interrupts (ich glaube das deutsche Windows hat das im Task Manager als "Systemunterbrechungen"). Damit hielt ich den Windows 8 Treiber von dem WiFi-Adapter für überführt und habe den folglich durch einen anderen China-WiFi-Adapter ersetzt (da ist sowieso immer der gleiche Broadcomm (?) Chip drin, ich habe keine finden können, die nicht Billig-China-Hardware sind)

Das Problem war dadurch schonmal besser (=seltener, weniger severe), aber noch nicht weg. Wegen 1) habe ich dann in beiden Browsern (Firefox, Chrome) die Hardwarebeschleunigung ausgemacht. Ich hatte sie erst nur in Firefox ausgemacht, daher weiß ich, dass das Problem definitiv auch mit Chromes Hardwarebeschleunigung besteht.

Seitdem habe ich manchmal das Phänomen, dass das System für 20 Sekunden langsamer wird, dann kurz Blackscreen (ich nehme an, Reset des GPU-Treibers), dann alles wieder OK. Ist nicht schön, kann ich aber mit leben.

Andere Dinge mit denen ich rumgespielt habe, in der Hoffnung dass es was bringt, die es aber vermutlich nicht waren:
- Taktrate RAM
- FreeSync ausmachen (NVIDIA Support für FreeSync ist ein bisschen wackelig)

Ich habe nicht den ganzen verlinkten Thread gelesen, aber ein paar Dinge fallen ins Auge:
Disable HW Acceleration in Firefox (from u/Aravind92)
Kann ich wie gesagt bestätigen, leider auch für Chrome und unabhängig davon welcher GPU-Vendor. Eine Erklärung, warum das hilft, habe ich nicht wirklich, insbesonder warum das Problem in - logischerweise Hardwarebeschleunigten - Spielen nicht auftritt.
A few users mention that it probably has a link with the GPU switching from idle to performance mode.
Das finde ich extrem plausibel gegeben meine Beobachtungen mit dem Phänomen. Wohlgemerkt, die CPU-Last geht auch hoch, aber ich weiß nicht was Ursache und was Wirkung ist.
I do 3D rendering, both CPU and GPU based for sometimes days at the time. The system is always stable during 100% load. But I can have a Skype call and have Firefox open, and clicking a link might freeze everything. Mouse pointer might update position once every few minutes. Skype call still goes on and we can continue to talk, but my screen is frozen - and I'm always also told my video froze up.
Genau das.

Was die möglichen Lösungen angeht:
- BIOS Updates machen mir immer noch Angst. Ist mit Laptops, wo die USV quai an Board ist ein bisschen einfacher. Würde ungerne das BIOS updaten, wenn ich es vermeiden kann. Im Thread ist man sich nicht einig, ob das BIOS wirklich das Problem ist.
- Ich würde ungerne Power-Management abschalten, weil ich vermute dass das System dann auch wirklich mehr Strom zieht und vor allem auch lauter und heißer wird.
- Vor allem habe ich keine Lust die Hardware nochmal zu tauschen, was ja auch nicht gratis ist.
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Update:

Gerade nachgesehen, das PowerManagement für PCI-Express war schon ausgeschaltet, daran liegt es also auch nicht.

3) Lustigerweise ist es aufgetreten während ich das obige tippte und ich kann bestätigen:

11:52

Die Beschreibung für die Ereignis-ID "14" aus der Quelle "nvlddmkm" wurde nicht gefunden. Entweder ist die Komponente, die dieses Ereignis auslöst, nicht auf dem lokalen Computer installiert, oder die Installation ist beschädigt. Sie können die Komponente auf dem lokalen Computer installieren oder reparieren.

Das ist genau die Event ID von der die leute berichten.

ab ca. 12.00 Uhr

System merklich langsamer. Ich will mich nicht zu sehr da reinsteigern, aber zwischen 11:52 und 12:00 kein aktiver Internetzugriff durch mich. Probleme fangen erst mit aktiver Benutzung des Netzwerks an.

12:08 Uhr

Der Anzeigetreiber "nvlddmkm" reagiert nicht mehr und wurde wiederhergestellt.

Kurzer Blackscreen, seitdem alles wieder gut.

Wieso die Leute im Thread sagen es wäre nicht der GPU-Treiber ist mir nicht klar. Das Symptom ist eindeutig der GPU-Treiber, auch wenn die Root Cause vielleicht woanders liegt.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: 14.06.2020, 11:53
I do 3D rendering, both CPU and GPU based for sometimes days at the time. The system is always stable during 100% load. But I can have a Skype call and have Firefox open, and clicking a link might freeze everything. Mouse pointer might update position once every few minutes. Skype call still goes on and we can continue to talk, but my screen is frozen - and I'm always also told my video froze up.
Genau das.
Dito. Volllast ist überhaupt kein Problem, weder CPU noch GPU. Aber irgendwann zwischendurch, wenn im Hintergrund ein YouTube-Video spielt und ich im Vordergrund was in Notepad eintippe, plötzlich BÄM. Und zwar nur alle paar Wochen.

Die Blackscreens halten so lange an, dass ich die Geduld verliere und neustarte (über 2 Minuten). Im Event Log steht zum Grafiktreiber dann Reset, Reset, Reset, Reset …

Energiesparmodi und Power Management habe ich auch schon erfolglos durchprobiert.

Dass du die Energiesparmodi nicht deaktivieren möchtest, verstehe ich. Auf meinem Desktop messe ich sowas wie 60 W vs. 70 W bei Energiesparplan vs. Höchstleistung, aber bei Mobilsystemen dürfte der Unterschied deutlich größer sein.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Nur um Missverständnisse zu vermeiden:

Mein Fall 1) ist ein Laptop. Fall 2) und 3) sind dasselbe System (Desktop). Der Kommentar zu Laptops unter 2) bezog sich nur darauf, dass ich bei Laptops weniger Angst vor BIOS Updates habe.

Treibersupport bei GIGABYTE scheint ohnehin abysmal zu sein. Ich weiß dass die Leute MSI genausowenig mögen, aber ich persönlich hatte mit MSI mehr Freude.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: 14.06.2020, 12:46Treibersupport bei GIGABYTE scheint ohnehin abysmal zu sein. Ich weiß dass die Leute MSI genausowenig mögen, aber ich persönlich hatte mit MSI mehr Freude.
Ja; bin bei MSI und … naja. Wie ich vorhin gelernt: Die Mainboard-Supplier schreiben ihre BIOSe nicht mehr selber, sondern bekommen von AMD das AGESA, klatschen ihr eigenes Logo rein, und stellen es auf ihre Website. Ich würde erwarten, dass die Qualitätsschwankungen dann nicht mehr so riesig sind.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Heise schreibt am 30.04 dass MSI AGESA 1.0.0.5 unterstützt (https://www.heise.de/newsticker/meldung ... 12689.html)

Gigabyte veröffentlicht am 28.05 (einen Monat später) eine neue BIOS Version, ohne Release Notes und laut Internet ohne AGESA 1.0.0.5 Support.

Da ärgere ich mich dann schon ein bisschen.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: 14.06.2020, 13:11Heise schreibt am 30.04 dass MSI AGESA 1.0.0.5 unterstützt (https://www.heise.de/newsticker/meldung ... 12689.html)

Gigabyte veröffentlicht am 28.05 (einen Monat später) eine neue BIOS Version, ohne Release Notes und laut Internet ohne AGESA 1.0.0.5 Support.

Da ärgere ich mich dann schon ein bisschen.
Fuuuuuuuuck. Immer wenn man denkt, es geht nicht schlimmer … mein Beileid.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Ihr müssts ja auch unbedingt herbeireden :'3

Und das war schon der zweite heut -.-
Dateianhänge
bsod.jpg
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Schrompf »

Ich ziehe jetzt mal besser das Netzwerkkabel vom heimischen Rechner, bevor ihr meine Heimcombo noch damit ansteckt.
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
scheichs
Establishment
Beiträge: 845
Registriert: 28.07.2010, 20:18

Re: Jammer-Thread

Beitrag von scheichs »

Ich habe Ryzen 3900x + RTX 2070. Super viele Dev-Tools drauf (Konsolen, Virtualisierung, etc.). Auf einer ollen B350-Krücke von MSI. Kann mich an keinen Absturz erinnern. Reboote aber jeden Tag und habe eine mega-alte Windows Version drauf, glaub 1809.

Ein Kollege von mir hatte mit Intel (Haswell) und GTX 1060 sporadische Bluescreens (glaube WATCHDOG). Unter Volllast keine Probleme. Nach -keine Ahnung- 1,5 Jahren hat er dann mal einen Memtest gemacht (weiss nichtmer welcher es war) und es war ein Speicherriegel wohl leicht defekt. Seitdem
Eventuell mal den Speichertakt etwas senken?
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Memtest war das erste, was ich probiert habe. Habe es zwei Tage laufen lassen; keine Fehler.

(Ich führe hier auch große Kompression mit 40+ GiB an Speicherbedarf durch und teste die CRCs, weil selbst intakter Speicher bei dieser Menge täglich einen Bitflip erfahren sollte, so lange es kein ECC-RAM ist – habe aber noch keine Inkonsistenzen gefunden.

[Ja, Krishty traut seinem RAM nicht mehr und der SSD auch nicht und CRCt seit Monaten kreuz und quer, konnte aber noch nie einen Fehler finden.])
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Ja, das ist ein guter Hinweis. Meine Kiste ist aber schon konservativ eingestellt, ich bin kein Freund von übertakten. Noch niedriger und ich muss schieben ^^

Ich bin hier grade richtig am rotieren. Ich hatte grade schon wieder einen BSOD. Das waren jetzt drei in Folge. Ich habe ja das neueste Update in Verdacht. Das passt einfach zu gut vom Timing. Wüsste aber nicht was genau ich da nun runterschmeissen müsste. Und das kommt ja dann trotzdem irgendwann wieder drauf.

BlueScreenView hat mir ntoskrnl.exe als Übeltäter gemeldet. Was nicht wirklich weiterhilft. Das ist der Windows Kernel. Das kann alles sein. Und WinDbg schmeisst auch einen falschen Parameter (0x80080057). Was auch wieder auf den Kernel zeigt. Und das kann immer noch alles sein.

Ich habe allerdings gerade meine Systemdateien mit sfc /scannow überprüft. Und das hat tatsächlich was gefunden und repariert. Windows üblich ist natürlich nicht rauszufinden was genau da nun repariert wurde, aber Fingers crossed dass es das war.

Auf neue Hardware hab ich gar keine Lust, die ist erst ein Jahr alt. Ryzen 3700x mit einer geforce gtx 1060. Und bis jetzt lief das eigentlich gut.
Zuletzt geändert von Tiles am 15.06.2020, 10:25, insgesamt 1-mal geändert.
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Tiles hat geschrieben: 15.06.2020, 09:30Ich habe allerdings gerade meine Systemdateien mit sfc /scannow überprüft. Und das hat tatsächlich was gefunden und repariert. Windows üblich ist natürlich nicht rauszufinden was genau da nun repariert wurde, aber Fingers crossed dass es das war.
Ha, hatte ich gestern!

Du musst in der Logdatei, die er dir nennt, nach sowas wie "repair" suchen. Bei mir hat er dann eine wirklich kritische Systemdatei repariert, die verloren gegangen war. Nämlich die Startmenü-Werbung für OneDrive!
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Matthias Gubisch
Establishment
Beiträge: 470
Registriert: 01.03.2009, 19:09

Re: Jammer-Thread

Beitrag von Matthias Gubisch »

Hmm also meine combo mit 3700x und RTX2080 Super auf nem X470 chipsatz hatte hier bisher auch keine Probleme
und das obwohl die CPU deutlich uebertaktet ist, laueft hier stabil mit 4GHz vor sich hin und wir nur alle heilige Zeit mal rebootet…
Hoff das bleibt auch so ;)

Aber AMD GPUs sind auch nix ;)
Bevor man den Kopf schüttelt, sollte man sich vergewissern einen zu haben
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

scheichs hat geschrieben: 15.06.2020, 09:09 Eventuell mal den Speichertakt etwas senken?
Hatte ich erfolglos probiert.
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Hm, haben wir denn alle den gleichen Error? Also ich hab den hier: https://docs.microsoft.com/en-us/window ... ot-handled
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Alexander Kornrumpf
Moderator
Beiträge: 2106
Registriert: 25.02.2009, 13:37

Re: Jammer-Thread

Beitrag von Alexander Kornrumpf »

Tiles hat geschrieben: 15.06.2020, 09:51 Hm, haben wir denn alle den gleichen Error? Also ich hab den hier: https://docs.microsoft.com/en-us/window ... ot-handled
Eher nicht, denn ich habe gar keine Bluescreens (mehr). Das "milde" Symptom ist "Event 14" im Event log und anschließender Reset des NVIDIA-Treibers.
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Krishty »

Alexander Kornrumpf hat geschrieben: 15.06.2020, 09:54
Tiles hat geschrieben: 15.06.2020, 09:51 Hm, haben wir denn alle den gleichen Error? Also ich hab den hier: https://docs.microsoft.com/en-us/window ... ot-handled
Eher nicht, denn ich habe gar keine Bluescreens (mehr). Das "milde" Symptom ist "Event 14" im Event log und anschließender Reset des NVIDIA-Treibers.
Dito; dein Fehler mutet mir nach etwas anderem an :)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Aber nicht minder ärgerlich :/
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Benutzeravatar
Tiles
Establishment
Beiträge: 1990
Registriert: 11.01.2003, 13:21
Kontaktdaten:

Re: Jammer-Thread

Beitrag von Tiles »

Die Kiste hört nicht mehr auf zu crashen. Inzwischen habe ich drei unterschiedliche Fehler zu Gesicht bekommen. Und letztenendes kann es laut Google immer noch alles sein. Software. Hardware. Virus. Treiber. Windows 10 Update. Und leider crasht es nicht oft genug um wirklich sinnvoll Fehlersuche machen zu können. Fies! -.-
Free Gamegraphics, Freeware Games https://www.reinerstilesets.de
Die deutsche 3D Community: https://www.3d-ring.de
Antworten