Arch Linux

wine: DirectX-Spiele langsam

CrUpf

Hallo Leute!

Ich habe folgenden Rechner:
AMDAthlon 3500+
ATI Radeon X1300 (256 MB GDDR3, Pixel Shader 3.0, DirectX 9.0, OpenGL 2 Support usw.)
1024 DDR400 RAM

Kernelversion: 2.6.27-ARCH
Grafiktreiber: proprietärer ATI Catalyst 8.11
Wineversion: 1.1.9 (per pacman installiert, wollte nichts speziell verändern und selbst kompilieren..)

betroffene Spiele: alle, die auf DirectX-Basis laufen.
Wc3 und CS kann man zum Beispiel über OpenGL laufen lassen (und laufen damit besser als unter Windows).
Aber Schlacht um Mittelerde zum Beispiel ist, soweit ich weiß, nur DirectX-fähig...

Habe eine sehr minimalistisch eingerichtetes System, kann also nicht an zu hoher Systemauslastung liegen.

Folgende Fehlermeldungen tauchen bei Schlacht um Mittelerde in der Konsole auf:

erst ein paar Cursor-Fehlermeldungen, ist aber nicht weiter schlimm, der Cursor funktioniert einwandfrei, ruckelfrei usw...

dann:

libGL error: drmMap of framebuffer failed (Nicht genügend Hauptspeicher verfügbar)
libGL error: reverting to (slow) indirect rendering

eine libgl Fehlermeldung? Warum!?
Auch habe ich mit Sicherheit genügend Hauptspeicher.
slow indirect rendering verstehe ich jetzt mal als Prozessor-Emulation statt Hardware Rendering, liege ich da richtig? Das könnte die schlechte Performance, speziell bei Partikeleffekten, Shadern, Schatten, Lichtern usw. erklären...

etwas weiter unten:

fixme:d3d:IWineD3DDeviceImp1_CreateSwapChain The app requests more than one back buffer, this can't be supported properly. Please configure the application to use double buffering(=1 back buffer) if possible
fixme:d3d:IWineD3DDeviceImp1_SetSoftwareVertexProcessing (0x3ba5078) : stub

Das heißt jetzt genau was?
Welches "buffering" ist gemeint, und wie kann ich "double buffering" aktivieren?

noch weiter unten etwa 100 mal:

fixme:d3d:debug_d3dformat Unrecognized 1 WINED3DFORMAT!
err:d3d:CheckTextureCapability Unhandled format=unrecognized
fixme:d3d:debug_d3dformat Unrecognized 2 WINED3DFORMAT!
err:d3d:CheckTextureCapability Unhandled format=unrecognized
fixme:d3d:debug_d3dformat Unrecognized 3 WINED3DFORMAT!
err:d3d:CheckTextureCapability Unhandled format=unrecognized
...

Wieso versteht WineD3D Formate nicht?

Danke schonmal im Voraus!

CrUpf

Ok, habe viel recherchiert.

Es liegt "nur" an diesem Fehler:

libGL error: drmMap of framebuffer failed (Nicht genügend Hauptspeicher verfügbar)
libGL error: reverting to (slow) indirect rendering

bzw.

libGL error: drmMap of framebuffer failed (cannot allocate memory)
libGL error: reverting to (slow) indirect rendering

Es ist ein globaler Fehler auf der gesamten Welt. Schuld ist ATI/AMD. Sie sind unfähig ordentliche Treiber programmieren. Ich habe eben erfahren, dass meine OpenGL-Unterstützung auch nur Linux-nativer Natur ist. Wieso Wc3 (im OpenGL-Modus) allerdings immernoch schneller unter wine ist, als unter Windows, kann eigentlich nur bedeuten, dass die Windowstreiber genauso schlecht sind.

Ein Treiberdowngrade hat einigen geholfen.

Aber:

Wie kann ich meine Paketstruktur so sauber halten, wie sie ist und gleichzeitig ein Paket downgraden, obwohl ich nicht die Pakete im pacman-Cache hab?
Meine Arch-Installation ist noch recht frisch...

CrUpf

Neuer Stand:

Downgraden wird nicht helfen. Habe eine vielversprechende Lösung gefunden:

http://bugs.winehq.org/show_bug.cgi?id=13335#c97
Anhang dazu:
http://bugs.winehq.org/attachment.cgi?id=17197&action=edit

Da geht es um mmap wrappers und ein C-Skript (glaube ich zumindest) namens virtual.diff, welches den Speicherzuteilungsbug von ATI behebt, aber ich kann damit nichts anfangen...
Was ist das?
Wie nutze ich das?

eiffel56

Hmpf, wieso hab ich den Thread nicht früher gesehen. Ich hätte dir die ganze Sucharbeit ersparen können ^^.

Ja, es liegt an der libGL Fehlermeldung. Indirect Rendering ist 3D ohne Hardwarebeschleunigung wie du schon richtig gesagt hast, und ja es liegt auch wirklich an dem ATI Treiber.
Die Datei im Attachment istn diff File. Um das in Wine sauber reinzupatchen machst du folgendes
Erstmal aktualisierst du deinen ABS tree und kopierst den Wine Ordner da raus. Den Patch speicherst du als Datei mit in den Ordner. PKGBUILD öffnen und den Patch bei source mit eintragen. Vor die configure Zeile in der build Funktion fügst du dann noch das ein:
patch -p1 -i ${srcdir}/namedespatches || return 1

Das ganze speichern und mit makepkg bauen. Am Ende(Wine compilieren dauert ein bisschen) fällt ein pkg.tar.gz File raus das du ganz normal mit Pacman installieren kannst.

Der Patch ist aber eher als Workaround zu verstehen. Der eigentliche Fehler liegt ja bei AMD. Ausserdem musst die die ganze Prozedur bei jeder Wine Version wieder manuell neu machen.

CrUpf

Danke für die Antwort dennoch 🙂

Ich habe sie aber eben erst gelesen. Vorhin habe ich Bekanntschaft mit diff und patch usw. gemacht. Dabei habe ich die wine-1.1.8 Sourcen von sourceforge geladen, da ich gemerkt habe, mit 1.1.9 funktioniert der hack nicht (mehr), da sich der Code bei einigen Dateien zu stark verändert hat und ich mich mit derartiger Programmierung und Problemlösung nicht auskenne.

Ich weiß nicht, ob im AUR noch eine 1.1.8 Version vorhanden gewesen wäre. Sonst hätte ich es wahrscheinlich so gemacht, wie du es beschrieben hast, wie dem auch sei, ich habe es jetzt per Hand kompiliert und installiert. Funktioniert einwandfrei, nur dass halt kein systemweiter link auf wine sitzt.

Es wurde angekündigt, den Memory Allocation Patch (leicht angepasst) ab 1.2.0 standardmäßig einzubauen, was für ATI-User wie mich ein schönes Weihnachtsgeschenk ist ^^.

(Bug 13335 wurde als einer der Major Priority Bugs für 1.2.0 gekennzeichnet, ob wirklich eine Lösung eingebaut wird, weiß ich nicht, aber man kann es hoffen.)

Grüße

eiffel56

Bitte merken: _Niemals_ an pacman vorbei Software installieren. Das hat böse Auswirkungen. Abhängigkeiten gehen kaputt und so weiter. Man kann sich damit beliebig das System zerschießen, du bekommst abstruse Fehlermeldungen, ...
Die Lösung wäre gewesen, im PKGBUILD die Variable pkgver von 1.1.9 auf 1.1.8 zu setzten->er baut Wine 1.1.8 mit deinem Patch.
Eine andere Lösung wäre den Patch zu portieren, was die beste Methode meiner Meinung nach ist. Da das nun nich jeder kann guck ich mal rein inwiefern man da groß was ändern muss.

Wenn du das jetzt machst hast du das Problem das Dateien in deinem Dateisystem liegen von denen Pacman nichts weiß. Der einzig saubere Weg das zu beheben ist die Dateien manuell zu löschen. Tust du das nicht wirst du kein Wine Paket mehr über Pacman installieren können(ausser du erzwingst das Ganze, aber sehr sehr sehr unsauber und macht noch mehr Probleme).
Um zu gucken welche Dateien Wine jetzt installiert hast wechselst du in den Ordner mit dem compilierten Wine(genau den, falls du ihn schon gelöscht hast neu runterladen(mit der richtigen Version!), patchen, ...)
Dann tippst du
make prefix=$PWD/../wine-installed-files install

In dem neuen Ordner guckst du dann welche Dateien dazugekommen sind und löschst sie wieder(in deinem Dateisystem natürlich).
Wine hat auch ein uninstall Script(make uninstall), aber da können natürlich auch wieder Reste bleiben.

Du siehst also, ein riesen Problem das ganze 😉. Die einfache Paketerstellung mithilfe von PKGBUILDs ist eine der großen Stärken von Arch Linux. Du solltest lernen damit umzugehen, dann wirst du es sehr zu schätzen wissen.
Aber gut zu wissen das der Patch funktioniert hat. Ob er so in Wine 1.2 reinkommt steht in den Sternen. Viele kleine Änderungen am Wine Sourcecode können Anwendungen beeinträchtigen. Das kann von "Anwendung XY startet nicht mehr" bis hin zu "In Spiel XY flackert der Mauszeiger" gehen. Bei letzterem ist es natürlich verdammt schwer drauf zu kommen das es ausgerechnet an dem ATI Patch liegt. Und im Endeffekt liegt der Fehler ja bei AMD soweit ich das verstanden habe. Wer weiß, vielleicht wird das ja schon von der Treiberseite her mit dem nächsten Update gefixt.

EDIT:
Der Patch funktioniert nicht mehr weil die unaligned_mmap Funktion(anscheinend ein Wrapper um mmap, der mehr Geschwindigkeit auf einem System mit Linux vor 2.4.0 bringt) entfernt wurde. Die angehängte Datei fügt sie wieder hinzu(und reversed somit Commit 28c411b6277bfe9410d563846a00b5eba8cd3987, http://source.winehq.org/git/wine.git/?a=commit;h=28c411b6277bfe9410d563846a00b5eba8cd3987) und enthält auch noch gleich den ATI Patch. Also einfach den angehängten Patch auf Wine 1.1.9 anwenden und das ganze sollte wieder tun.
Programmiertechnisch ist das eher ein böser Hack, aber es funktioniert =D. Irgendwann wird sich jemand erbarmen und das richtig machen.
Es ist eigentlich richtig das die Funktion entfernt wurde. Sie ist einfach nutzlos und unschön.

ChemBro

eiffel56 schrieb Ja, es liegt an der libGL Fehlermeldung. Indirect Rendering ist 3D ohne Hardwarebeschleunigung wie du schon richtig gesagt hast, und ja es liegt auch wirklich an dem ATI Treiber.

Genau genommen liegt der Fehler bei demjenigen, der den ATI-Treiber fehlerhaft installiert hat. Eine libGL Fehlermeldung kann u.a. daran liegen, dass der Benutzer die xorg.conf nicht richtig gefüttert hat. Dafür kann AMD/ATI selbst nichts.

CrUpf

@ eiffel
wow, danke 🙂
Habe eben make uninstall und bin noch auf der suche nach verbleibenden Fragmenten - werde ich nun zu vermeiden wissen ^^ - dann werde ich mir ein Package mit den 1.1.9 Sourcen bauen und den Hack, Patch, wie auch immer, von dir reinspielen.

@ chembro

Soweit ich das verstanden habe, sichert sich wine einen gewissen Anteil an Speicher zu (welchen, was, wieviel, wo genau weiß ich nicht), welcher dann nicht mehr vom ATI-Treiber genutzt werden kann, weil da wohl irgendeine Option o. ä. im Treiber fehlt, um sich selbst den entsprechenden Speicher zuzusichern. Deshalb auch "cannot allocate memory". Das hat mit der libGL.so an sich nichts zu tun. Die funktioniert einwandfrei 😉. Es ist alles richtig installiert und konfiguriert.

CrUpf

Habe mein System noch mal neu installiert, diesmal die 64bit-Variante.

Wie füge ich hier
http://aur.archlinux.org/packages/bin32-wine/bin32-wine/PKGBUILD
den Patch ein? Es werden ja nur Binaries kopiert...

edit: Die Arbeit ist es nicht wert. Arch32 erhebt sich wieder...