linuxgaming.de

Es werden keine neuen Pakete für Mesa in diesem Repository veröffentlicht, sämtliche alten Binaries werden entfernt!

Seit einiger Zeit liefert Debian nun auch den d3d9-State-Tracker im eigenen Repo aus, daher ist es schon länger nicht mehr notwendig, diese Pakete aus meinem Repo zu beziehen. Die Zeit die ins Land geht, bis die Maintainer neue Versionen veröffentlichen, sind meiner Meinung nach ebenfalls angemessen, sodass erst mal kein Bedarf mehr an meinen Paketen bestehen dürfte. Ich werde die Builds von libdrm, libclc und mesa entfernen, sowie einige andere, veraltete Pakete. In Zukunft werden im Repo allerdings noch andere interessante, Gaming-bezogene Pakete veröffentlicht, die man so in den offiziellen Repos nicht findet. Ein neuer Thread wird dazu nächste Woche mehr Infos liefern.

In diesem Sinne ... I'll be back!

Rückblick zu Archivierungszwecken:

- Mesa 19.1.0 (ohne die Debian-Patches für HURD oder PPC)
- libstrangle Gitlab-Schnappschuss vom 15.11.18
- protontricks - ein Winetricks-Wrapper für Proton [veraltet]
- Ferals libgamemode (aktuell 1.2.6, die gleiche Version scheint aber auch inzwischen in den offiziellen Repos aufgetaucht zu sein)
- Übergangspakete, damit libd3d9-mesa durch libd3dadapter9-mesa ersetzt wird
- adriconf, weil der Entwickler sich dafür entschieden hat, nur Flatpaks zur Verfügung zu stellen

Für die Nutzung meines Repositories wird zwingend das Paket apt-transport-https benötigt, da mein Webserver automatisch jeglichen HTTP-Traffic auf HTTPS umleitet. Für die Datei /etc/apt/sources.list oder eine eigenständige Datei in /etc/apt/sources.list.d/ benötigt ihr dann die folgende Zeile:

Code: Alles auswählen

deb https://deb.c-r-t.tk/packages/debian unstable main

Danach importiert ihr den Public-Key für das Repository mit dem folgenden Befehl:

Code: Alles auswählen

# wget -O - https://deb.c-r-t.tk/crt0mega.gpg.key|apt-key add -

Mittels apt-get update aktualisiert ihr wie gewohnt die Paketquellen. Wenn ihr möchtet, dass meine Pakete gegenüber den Paketen aus den offiziellen Debian-Archiven Vorrang haben sollen, dann installiert bitte das Paket apt-pin-mesa und aktualisiert anschließend wieder die Paketquellen. Bei der nächsten Paketaktualisierung werden die Pakete aus meinem Repository installiert. Ihr könnt statt des Paketes apt-pin-mesa auch einen eigenen Eintrag dafür in dem Ordner /etc/apt/preferences.d anlegen. Beachtet bitte, dass ein Downgrade bereits bestehender Pakete aus Debian nicht mit einer Priorität unter 1000 möglich ist.

Weitere Tipps zum Tuning des Treibers findet ihr im berühmten padoka PPA.

Weitere Infos: deb.c-r-t.tk
Support: crt0mega auf irc.freenode.net, admin@c-r-t.tk via xmpp

Tipp: protontricks hat eine experimentelle Zenity-Gui bekommen, die ihr über "protontricks gui" aufrufen könnt. Wenn ich Bock & Zeit habe, baue ich dafür noch ein .desktop-File

Stets frische Kernel mit DC-Patches

Hinweis: Ab 4.15 braucht ihr keine Custom-Kernel mehr für VEGA, aber der oben genannte soll trotzdem noch ein paar Vorteile bieten.

Edit 15.06.19: Neue Version

Kann ich das auch unter testing nutzen? Mesa 1.11 hats ja inzwischen bis testing geschafft.

Im Moment steh ich auf'm Schlauch. Stable lief mit fglrx gut bis letzte Woche, jetzt mußte ich wegen veralteter SSL-Implementierung auf testing upgraden - dort gibts leider kein fglrx mehr und mit den radeon-Treibern rendert gar nichts mehr.

Und welche Wine-Version braucht man dazu? In POL gibts nur eine 1.7.55-d3dadapter Version, aber nur für 32bit - ich brauch 64bit und hätts außerdem gern aktueller. Leider finde ich nirgends eine vernünftige Anleitung für Debian, alles dreht sich immer nur um 'buntu ....

Für Mesa/Gallium-Nine wirst du mit dem fglrx eh nichts anfangen können. Und für/mit i386-Wine wirst du auch das i386-Mesa brauchen, um etwas sehen zu können.

Zu Ubuntu/Debian: Da Ubuntu sich größtenteils von Debian bedient, was die Pakete angeht, funktionieren die meisten Ubuntu-Anleitungen auch für Debian.

Moin moin!

kaimon hat geschrieben:Kann ich das auch unter testing nutzen? Mesa 11.1 hats ja inzwischen bis testing geschafft.

Getestet habe ich es nicht, aber es sollte eigentlich funktionieren. Aktuell habe ich 11.2 RC3 drin.

kaimon hat geschrieben:[...] dort gibts leider kein fglrx mehr und mit den radeon-Treibern rendert gar nichts mehr.

Hmm, du brauchst auch noch das Paket linux-firmware-nonfree, wenn ich mich nicht irre. Normalerweise sollte auch mit 11.1 aus testing alles laufen, was von AMD gerade auf dem Markt ist O.o
Nachtrag: Und, wie Bauer87 schon sagte, die 32-Bit-Pakete für Mesa. Siehe Multiarch

kaimon hat geschrieben:Und welche Wine-Version braucht man dazu? In POL gibts nur eine 1.7.55-d3dadapter Version, aber nur für 32bit - ich brauch 64bit und hätts außerdem gern aktueller. Leider finde ich nirgends eine vernünftige Anleitung für Debian, alles dreht sich immer nur um 'buntu ....

Ich glaube, die 1.7.55er war auch nur ein Fake. Hatte die mal probiert, freudig Screenshots mit Risen 3 gepostet und dann festgestellt, dass der d3dadapter gar nicht verwendet wurde. Im Moment nehme ich das noch ältere Paket "1.7.44-gallium-nine". Zu 32/64Bit: Ist egal, du kannst beide verwenden. In den meisten Fällen bin ich mit einer 32Bit-Version sogar besser gefahren. Du müsstest dann allerdings Multiarch verwenden:

Code: Alles auswählen

su -c "dpkg --add-architecture i386 && apt-get update"

(Wenn ich mich nicht irre.)
Ich habe leider die gleichen Erfahrungen gemacht, alles für Ubuntu und dessen Ableger. Leider ist es mir noch nicht geglückt, eine aktuelle Wine-Version mit den Gallium-Nine-Patches zu versehen und erfolgreich zu kompilieren, sonst hätte ich die auch gerne in's Repo gesteckt

Moin!
Das Repo mit 11.1 hast Du nicht mehr? Schade, das ginge besser für Testing ...

Zu 32/64Bit: Ist egal, du kannst beide verwenden. In den meisten Fällen bin ich mit einer 32Bit-Version sogar besser gefahren.

Ich schrieb, daß ich 64bit brauche ... Mit 32bit Varianten kann ich nichts anfangen, ich starte ein 64bit Programm und das braucht wine64. Insoweit ist es nicht egal.
Ich meinte übrigens wine 1.7.44-d3dadapter - hatte mich verschrieben.

Nachtrag: Und, wie Bauer87 schon sagte, die 32-Bit-Pakete für Mesa. Siehe Multiarch

Ist denn dein Repo auch nur für 32bit?

Also im Ergebnis müßte ich zumindest wine64 selbst kompilieren und du hast es schon nicht rausbekommen ... mist :-(

Hmm, du brauchst auch noch das Paket linux-firmware-nonfree, wenn ich mich nicht irre.

Das nutzt nix, denn testing enthält zur Zeit keine AMD-Treiber - die sind zu buggy. Wann die wiederkommen, ist völlig offen.

kaimon hat geschrieben:Das Repo mit 11.1 hast Du nicht mehr? Schade, das ginge besser für Testing ...

Tut mir leid, ich versuche immer, es so aktuell wie möglich zu halten. Es ist halt eigentlich für Unstable gedacht xD

kaimon hat geschrieben:Ich schrieb, daß ich 64bit brauche ... Mit 32bit Varianten kann ich nichts anfangen, ich starte ein 64bit Programm und das braucht wine64. Insoweit ist es nicht egal.

Ach mist. Mit 64-Bit-Wine sieht's über PoL ja noch schlimmer aus. Da empfehle ich dann, falls du mit der alten Wine-Version für Gallium-Nine nicht glücklich wirst "wine-staging" bis Version 1.9.5 (die 1.9.6er bringt zwar Vulkan-Unterstützung, schafft dafür aber die CSMT-Patches ab). Wine mit CSMT bringt zwar nicht so viel Performance, wie Gallium-Nine, aber es ist immer noch besser, als "Vanilla".

kaimon hat geschrieben:Ist denn dein Repo auch nur für 32bit?

Nee, keine Sorge. Da sind Pakete für amd64 und i386 drin, die laufen unabhängig voneinander.

kaimon hat geschrieben:Also im Ergebnis müßte ich zumindest wine64 selbst kompilieren und du hast es schon nicht rausbekommen ... mist :-(

Ja.. irgendjemand müsste mal die Patches an eine aktuellere Wine-Version angleichen und das liegt leider über meinem Horizont ... wenn ich mal wieder mehr Zeit habe, kümmere ich mich wieder darum und recherchiere ein wenig. Ursprünglich war's ja geplant, dass man auch Wine mit Gallium-Nine über mein Repo beziehen kann. Im Moment bin ich froh, wenn ich 11.2 mal mit LLVM 3.8 zum laufen bekäme...

kaimon hat geschrieben:Das nutzt nix, denn testing enthält zur Zeit keine AMD-Treiber - die sind zu buggy. Wann die wiederkommen, ist völlig offen.

Nee, das Paket firmware-linux-nonfree ist ja für die freien Treiber (trotz leicht irreführendem Namen). Ohne das Paket laufen die nicht wirklich rund.

Hast du dir schon mal überlegt, das direkt in Sid zu maintainen? Oder gibt es da Vorbehalte von dir/Debian?

Wenn das Debian-X-Strike-Force Team es nicht möchte, dann wird daraus nix. Jemand anderes hat da auch schon mal nachgefragt: Debian Bug report logs - #781078. Mal sehen, vielleicht wird mal in ferner Zukunft was daraus, DRI3 und LLVM 3.8 haben sie ja inzwischen auch aktiviert.

Zur Info: Mein Key ist abgelaufen und wurde soeben erneuert!

Code: Alles auswählen

# wget -O - https://deb.c-r-t.tk/crt0mega.gpg.key|apt-key add -

Side-Note: Ich sollte mir das mal auf Wiedervorlage setzen

Ich hab' da mal eine Frage an die Radeon-Enthusiasten hier im Forum. Gibt es jemanden, der aktuell unter Debian (vmtl. eher testing oder unstable) AMDGPU-PRO einsetzt oder gerne einsetzen würde? Ich überlege, mein Repo ein bisschen zu erweitern. Tellerrand und so. Offenbar ist der zumindest für Ubuntu 16.04 vorpaketiert. Mit ein bisschen Handarbeit und einem extra Meta-Paket sollte der sich jedenfalls einpflegen lassen.

Hier die offiziell unterstützen Karten des Treibers:

So, seit gestern ist 12.0.1 in meinem Repo oben. Ich war so frei, noch ein paar weitere Patches hinzuzufügen, die mir quasi über den Weg gelaufen sind. Diese Version wurde allerdings noch nicht mit LLVM 3.9 kompiliert – also noch kein OpenGL 4.3 für RadeonSI-User. Erst, wenn Kernel 4.7 und LLVM 3.9 in unstable landen

So es ist geschehen mesa kann jetzt OpenGL 4.5 zumindest mit Intel Treiber. Hoffe das jetzt mehr Optimierungen kommen werden und Vulkan.

Aye, ich bin mal gespannt. Die News zu Mesa werden von Mal zu Mal interessanter. Vielleicht wird ja auch aus "radv" auch was

Also Optimierungen kann man ja machen, aber bei den Intel-GPUs haben ja nicht alle OpenGL 4.5, sondern nur die neuesten Chips. Da is noch Arbeit. Dann halt noch OpenGL ES 3.2, da fehlt noch sehr viel. Und im Herbst soll ja noch OpenGL 4.6 kommen. Aber zumindest kann Herr Larabel mal aufhören zu schreiben, wie viele Jahre der freie Treiber hinterher hinkt.

ChemicalBrother hat geschrieben:[...] Aber zumindest kann Herr Larabel mal aufhören zu schreiben, wie viele Jahre der freie Treiber hinterher hinkt.

YMMD