crazy-biscuit
Supporter
Anmeldungsdatum: 6. November 2010
Beiträge: 4844
|
k2-IT schrieb: Die VEGA ist ja auch noch nicht soooo lange auf dem Markt für freie Treiber-Entwicklung –- und "Respekt und Anerkennung" für Programmierer wie Martin (M-Bab), die ihre Zeit und Energie dafür aufwenden, Software zu schreiben, die eigentlich von den Herstellern kommen sollte. Es ist sicherlich noch einiges zu tun, insbesondere die Performance dürfte noch gesteigert werden, aber wenn die neu Hardware schon mit dem richtigen Treiber Out-of-the-Box läuft, ist schon alles im Flow.
Na, na, na - AMD entwickelt den freien Treiber schon selbst! Es ist OpenSource, darum entwickeln auch Entwickler von RedHat oder Valve mit - und Menschen in ihrer Freizeit: Danke an alle Beteiligten! Aber so zu tun als würde AMD nichts machen ist schlichtweg falsch. Mit 4.18 und dem dann aktuellen Mesa- und AMDGPU-Treiber sollte es relativ problemlos laufen.
|
k2-IT
Anmeldungsdatum: 28. Juni 2007
Beiträge: 6
|
hakel schrieb: Ich muß juhuu irgendwie zustimmen. Warum sollte sich mit 18.04.1 etwas "geändert" haben?
Nun, weil 18.04.01 jetzt den AMDGPU-Treiber verwendet, während 18.04 noch mit VESA lief - und das ist der Unterschied auf den es ankommt, jetzt ist der vorgesehene Treiber integriert. Aber, weiß jemand, ob das mit dem Ryzen 3 und Vega 8 auch schon funktioniert? Die c't hat heute in 17/2018 einen Bauvorschlag mit Ryzen 3 präsentiert, dessen VEGA-Grafik sie weder mit Fedora 27 noch mit Ubuntu 18.04 ansprechen konnte. War aber allerdings nur 18.04. Deshalb meine Frage: Hat schon jemand 18.04.01 mit einem Ryzen 3 getestet? Mir fehlt noch ein Bürorechner... Grüße
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
k2-IT schrieb: hakel schrieb: Ich muß juhuu irgendwie zustimmen. Warum sollte sich mit 18.04.1 etwas "geändert" haben?
Nun, weil 18.04.01 jetzt den AMDGPU-Treiber verwendet, während 18.04 noch mit VESA lief - und das ist der Unterschied auf den es ankommt, jetzt ist der vorgesehene Treiber integriert. Aber, weiß jemand, ob das mit dem Ryzen 3 und Vega 8 auch schon funktioniert? Die c't hat heute in 17/2018 einen Bauvorschlag mit Ryzen 3 präsentiert, dessen VEGA-Grafik sie weder mit Fedora 27 noch mit Ubuntu 18.04 ansprechen konnte. War aber allerdings nur 18.04. Deshalb meine Frage: Hat schon jemand 18.04.01 mit einem Ryzen 3 getestet? Mir fehlt noch ein Bürorechner... Grüße
den Heise-Bauvorschlag habe ich leider nicht um dazu was zu sagen. Mein mainboard hat einen amd-b350 Chipsatz, der Bauvorschlag von Heise soll ein b360 sein. Bei mir läuft - jetzt seit fast 3 Monaten - folgendes:
CPU AMD Ryzen-3-2200G (genutzt wird nur die amdgpu als Grafikausgabe) mainboard ASUS PRIME B350-PLUS mehrere SATA-Festplatten Marvell-SATA-Kontrollerkarte für weitere 4 SATA-Ports dvb-SAT-Karte (saa7146)
nach LUbuntu-18.04 mit dem die Installation gemacht wurde läuft jetzt die Version 18.04.1
allerdings mit einem Ubuntu-Kernel 4.17.11 und das mesa 18.1.5 von padoka, sowie die amd-Firmware für RAVEN(so wird die VEGA-gpu bei dieser Ryzen-3-CPU-Version genannt). Wegen der Marvell-SATA-Kontrollerkarte musste ich iommu=soft setzen, weil sonst diese Karte nicht richtig erkannte wurde, d.h. die Festplatten daran. Als Besonderheit habe ich bei den Bootoptionen "noquiet, nosplash, iommu=soft" gesetzt und in /etc/sysctl.conf kernel.randomize_va_space=0 und kernel.sysrq=1 eingetragen. Im BIOS habe ich das secure-boot-Feature abgeschaltet. Boot-Probleme hatte ich keine, wenn ich davon absehe, dass die SATA-Kontrollerkarte am Anfang Probleme machte und die daran angeschlossenen Festplatten nicht richtig erkannt wurden. Der Reboot aus Linux hat auch bisher immer funktioniert, d.h. ich brauchte da auch keine besondere Option für andere Methoden (wie z.B. übers BIOS). An weiteren Änderungen habe ich seit wenigen Tagen einmal die für die gpu im BIOS vorgesehene Speichergröße von "AUTO" auf 512MB gesetzt. Eine Änderung (speziell bei Spielen wie openarena, doom3, quake4 .. ) konnte ich aber nicht feststellen. Der verfügbare Speicher scheint geringfügig kleiner zu sein, d.h. ich habe die Vermutung, dass in der Einstellung "AUTO" nur der kleinste Wert von 64MB für die Graka genutzt wird. Interessant wäre vielleicht noch, dass ich einmal bei ASUS nachgefragt habe, weil nach dem BIOS Update plötzlich eine Konfigurationsoption für besondere Energieeinsparung im BIOS verschwunden war. Die Antwort lautete ungefähr, dass so lange das BIOS funktionieren würde und die CPU Geschwindigkeit korrekt gesetzt sei, es keinen Grund gäbe deswegen aktiv zu werden. Unterschiedliche BIOS-Versionen könnten schon unterschiedliche Optionen haben und es wäre möglich, dass in den neueren BIOS-Versionen das "energy saving profile" eben nicht mehr vorhanden wäre. Ich hatte mir leider die Einstellungen dafür nicht notiert, so dass ich jetzt natürlich nicht weiß ob es noch irgendwo eine Einstellung gibt, mit der noch mehr Energie gespart werden könnte. Die 2 anderen "profiles" für "normal" und "optimal" sind allerdings vorhanden. Ein BIOS-screenshot und ein screenshot unter Linux mit unterschiedlichen gleichzeitigen Video/Audioausgaben.
- Bilder
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Das ist der bekannte "Status Quo". Ein Normalo sollte die Finger davon lassen.
die Vermutung, dass in der Einstellung "AUTO" nur der kleinste Wert von 64MB für die Graka genutzt wird.
Der Treiber sollte die Einstellung im UEFI ignorieren. Nur hochwertige moderne Spiele nutzen VRAM >512MB. Die von dir aufgeführten Spiele sind ANNO 2018 irrelevant. Warten wir mal ab was 18.10 bringt. ☹
|
k2-IT
Anmeldungsdatum: 28. Juni 2007
Beiträge: 6
|
alterpinguin schrieb:
den Heise-Bauvorschlag habe ich leider nicht um dazu was zu sagen. Mein mainboard hat einen amd-b350 Chipsatz, der Bauvorschlag von Heise soll ein b360 sein.
Bei Heise war es ebenfalls ein B350-Chipsatz, allerdings auf dem MSI B350M Mortar; der B360 ist ein Intel-Chipsatz alterpinguin schrieb: nach LUbuntu-18.04 mit dem die Installation gemacht wurde läuft jetzt die Version 18.04.1
allerdings mit einem Ubuntu-Kernel 4.17.11 und das mesa 18.1.5 von padoka, sowie die amd-Firmware für RAVEN(so wird die VEGA-gpu bei dieser Ryzen-3-CPU-Version genannt).
Könntest Du mal von einem Live-Lubuntu-18.04.01 booten und dann in der /var/log/Xorg.0.log nachschauen, was für ein Treiber dort verwendet wird? Das würde zeigen ob Lubuntu 18.04.01 auch den Ryzen3 nativ unterstützt. Danke!
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
k2-IT schrieb: alterpinguin schrieb:
den Heise-Bauvorschlag habe ich leider nicht um dazu was zu sagen. Mein mainboard hat einen amd-b350 Chipsatz, der Bauvorschlag von Heise soll ein b360 sein.
Bei Heise war es ebenfalls ein B350-Chipsatz, allerdings auf dem MSI B350M Mortar; der B360 ist ein Intel-Chipsatz alterpinguin schrieb: nach LUbuntu-18.04 mit dem die Installation gemacht wurde läuft jetzt die Version 18.04.1
allerdings mit einem Ubuntu-Kernel 4.17.11 und das mesa 18.1.5 von padoka, sowie die amd-Firmware für RAVEN(so wird die VEGA-gpu bei dieser Ryzen-3-CPU-Version genannt).
Könntest Du mal von einem Live-Lubuntu-18.04.01 booten und dann in der /var/log/Xorg.0.log nachschauen, was für ein Treiber dort verwendet wird? Das würde zeigen ob Lubuntu 18.04.01 auch den Ryzen3 nativ unterstützt. Danke!
mmmh – dann ist das bei Heise noch merkwürdiger, dass die das nicht hinbekommen haben. Aber zu Deinem Wunsch. Damit war meine Uptime für heute natürlich gelaufen. Das hat auch länger gedauert. Das erste Bild zeigt den Bildschirm nach einem Boot von Ubuntu-18.04.1 von einem USB-Stick ohne jeglichen Eingriff (Bild A mit der
Verdoppelung des Bildschirminhalts - es geht dann nur noch SysRq oder man versucht auf die Console zu kommen um den Rechner neu zu starten). Bild B zeigt dann, dass man "nomodeset" auswählt (es fehlt natürlich das Bild, dass man die Tastaturbelegung setzt -z.B. mit Pfeiltaste nach Rechts). Bild C zeigt die manuellen Änderungen von quiet auf noquiet und splash auf nosplash sowie den Zusatz iommu=soft (für Nichtkenner der US-Tastatur, das Gleichheitszeichen liegt .. auf der Taste ß oder daneben .. mmh da war wohl das Bierglas dran Schuld, dass ich das schon ohne viel nachdenken eintippe). Bild D zeigt dann, dass der Bootvorgang sehr schön kommentiert wird, statt eines nichtssagenden leeren Bildschirms – manche fühlen sich natürlich von so viel Bleiwüste "beleidigt", ich find es schöner als irgendwelchen grafischen rotierenden oder hoppsenden Schnickschnack. Bild E zeigt nochmal diverse Grafik"störungen" - aber nicht erschrecken, denn dann kommt Bild F und es sieht schon mal fast typisch Ubuntu aus, d.h. da kann man dann sich mit der Maus austoben. Jetzt zu den Angaben von X11(org), da wird offenbar auch bei 18.04.1 vesa benutzt, denn vom AMDgpu ist nichts zu sehen, im Gegenteil zu meinem endgültig installierten System mit neuerem Kernel (Auszug aus Xorg-log:
.....
[ 32.117] (II) Applying OutputClass "AMDgpu" to /dev/dri/card0
[ 32.117] loading driver: amdgpu
[ 32.117] (==) Matched amdgpu as autoconfigured driver 0
[ 32.117] (==) Matched ati as autoconfigured driver 1
[ 32.117] (==) Matched ati as autoconfigured driver 2
[ 32.117] (==) Matched modesetting as autoconfigured driver 3
[ 32.117] (==) Matched fbdev as autoconfigured driver 4
[ 32.117] (==) Matched vesa as autoconfigured driver 5
[ 32.117] (==) Assigned the driver to the xf86ConfigLayout
[ 32.117] (II) LoadModule: "amdgpu"
[ 32.117] (II) Loading /usr/lib/xorg/modules/drivers/amdgpu_drv.so
[ 32.196] (II) Module amdgpu: vendor="X.Org Foundation"
[ 32.196] compiled for 1.19.6, module version = 18.0.1
[ 32.196] Module class: X.Org Video Driver
[ 32.196] ABI class: X.Org Video Driver, version 23.0
..... Also unterstützt die Live-Version auch mit 18.04.1 noch nicht die AMD-Raven-gpu vom Ryzen-3-2200G. ps. solche Bilder von "Grafikstörungen" sind mir übrigens schon von älterer Hardware bekannt, deshalb denke ich mir eigentlich nicht viel dabei und suche halt nach den passenden boot-Optionen und ob später ein besser passender Treiber installiert werden kann.
- Bilder
|
crazy-biscuit
Supporter
Anmeldungsdatum: 6. November 2010
Beiträge: 4844
|
Es würde mich auch sehr wundern, wenn 18.04.1 das oob könnte. Von welcher Distro soll das denn zurückportiert worden sein? 18.10 pre-Alpha? HWE gibt es jeweils nur von einer aktuelleren Release-Version. Korrigiert mich wenn ich falsch liege.
|
k2-IT
Anmeldungsdatum: 28. Juni 2007
Beiträge: 6
|
@alterpinguin: Erst mal herzlichen Dank für Deine Mühe! alterpinguin schrieb: Jetzt zu den Angaben von X11(org), da wird offenbar auch bei 18.04.1 vesa benutzt, denn vom AMDgpu ist nichts zu sehen, im Gegenteil zu meinem endgültig installierten System mit neuerem Kernel (Auszug aus Xorg-log:
Kann ich Deinem Auszug leider nicht entnehmen. amdgpu, ati, modesetting, framebuffer und vesa werden zwar geladen, aber welcher benutzt und welche wieder "entladen" werden steht leider nicht drin. Bei mir sieht der entsprechende Teil dann so aus: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 | [ 4.411] (II) UnloadModule: "radeon"
[ 4.411] (II) Unloading radeon
[ 4.411] (II) UnloadModule: "modesetting"
[ 4.411] (II) Unloading modesetting
[ 4.411] (II) UnloadModule: "fbdev"
[ 4.411] (II) Unloading fbdev
[ 4.411] (II) UnloadSubModule: "fbdevhw"
[ 4.411] (II) Unloading fbdevhw
[ 4.411] (II) UnloadModule: "vesa"
[ 4.411] (II) Unloading vesa
[ 4.411] (--) Depth 24 pixmap format is 32 bpp
[ 4.411] (II) AMDGPU(0): [DRI2] Setup complete
[ 4.411] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 4.411] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
[ 4.411] (II) AMDGPU(0): Front buffer pitch: 7680 bytes
[ 4.412] (II) AMDGPU(0): SYNC extension fences enabled
[ 4.412] (II) AMDGPU(0): Present extension enabled
[ 4.412] (==) AMDGPU(0): DRI3 enabled
[ 4.412] (==) AMDGPU(0): Backing store enabled
[ 4.412] (II) AMDGPU(0): Direct rendering enabled
[ 4.430] (II) AMDGPU(0): Use GLAMOR acceleration.
[ 4.430] (II) AMDGPU(0): Acceleration enabled
[ 4.430] (==) AMDGPU(0): DPMS enabled
[ 4.430] (==) AMDGPU(0): Silken mouse enabled
[ 4.430] (II) AMDGPU(0): Set up textured video (glamor)
[ 4.430] (II) AMDGPU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
|
alterpinguin schrieb: Also unterstützt die Live-Version auch mit 18.04.1 noch nicht die AMD-Raven-gpu vom Ryzen-3-2200G.
Ja, sieht tatsächlich so aus, als würde der sich VEGA-8-Kern im Ryzen 3 gegenüber dem VEGA-11-Kern im Ryzen 5 anders verhalten...
Bei mir lief die Installation von Lubuntu 18.04.01 ohne irgendwelche Eingriffe in die Bootparameter und das System arbeitete mit dem AMDGPU-Treiber. Btw. <klugschiss> Die CPU heißt Ryzen, der Grafikkern VEGA, Die APU CPU+GPU wollten sie früher einmal Raven nennen - heißt jetzt Ryzen x xxxxG </klugschiss> alterpinguin schrieb: ps. solche Bilder von "Grafikstörungen" sind mir übrigens schon von älterer Hardware bekannt, deshalb denke ich mir eigentlich nicht viel dabei und suche halt nach den passenden boot-Optionen und ob später ein besser passender Treiber installiert werden kann.
Jeep - das war bei mir auch immer so mit den APUs - oder auch bei den Grafikkernen im Chipsatz Grüße - und wir warten weiter... - oder verbauen einen Ryzen 5 2400G...
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
k2-IT schrieb: @alterpinguin: Erst mal herzlichen Dank für Deine Mühe! alterpinguin schrieb: Jetzt zu den Angaben von X11(org), da wird offenbar auch bei 18.04.1 vesa benutzt, denn vom AMDgpu ist nichts zu sehen, im Gegenteil zu meinem endgültig installierten System mit neuerem Kernel (Auszug aus Xorg-log:
Kann ich Deinem Auszug leider nicht entnehmen. amdgpu, ati, modesetting, framebuffer und vesa werden zwar geladen, aber welcher benutzt und welche wieder "entladen" werden steht leider nicht drin. Bei mir sieht der entsprechende Teil dann so aus: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 | [ 4.411] (II) UnloadModule: "radeon"
[ 4.411] (II) Unloading radeon
[ 4.411] (II) UnloadModule: "modesetting"
[ 4.411] (II) Unloading modesetting
[ 4.411] (II) UnloadModule: "fbdev"
[ 4.411] (II) Unloading fbdev
[ 4.411] (II) UnloadSubModule: "fbdevhw"
[ 4.411] (II) Unloading fbdevhw
[ 4.411] (II) UnloadModule: "vesa"
[ 4.411] (II) Unloading vesa
[ 4.411] (--) Depth 24 pixmap format is 32 bpp
[ 4.411] (II) AMDGPU(0): [DRI2] Setup complete
[ 4.411] (II) AMDGPU(0): [DRI2] DRI driver: radeonsi
[ 4.411] (II) AMDGPU(0): [DRI2] VDPAU driver: radeonsi
[ 4.411] (II) AMDGPU(0): Front buffer pitch: 7680 bytes
[ 4.412] (II) AMDGPU(0): SYNC extension fences enabled
[ 4.412] (II) AMDGPU(0): Present extension enabled
[ 4.412] (==) AMDGPU(0): DRI3 enabled
[ 4.412] (==) AMDGPU(0): Backing store enabled
[ 4.412] (II) AMDGPU(0): Direct rendering enabled
[ 4.430] (II) AMDGPU(0): Use GLAMOR acceleration.
[ 4.430] (II) AMDGPU(0): Acceleration enabled
[ 4.430] (==) AMDGPU(0): DPMS enabled
[ 4.430] (==) AMDGPU(0): Silken mouse enabled
[ 4.430] (II) AMDGPU(0): Set up textured video (glamor)
[ 4.430] (II) AMDGPU(0): RandR 1.2 enabled, ignore the following RandR disabled message.
|
alterpinguin schrieb: Also unterstützt die Live-Version auch mit 18.04.1 noch nicht die AMD-Raven-gpu vom Ryzen-3-2200G.
Ja, sieht tatsächlich so aus, als würde der sich VEGA-8-Kern im Ryzen 3 gegenüber dem VEGA-11-Kern im Ryzen 5 anders verhalten...
Bei mir lief die Installation von Lubuntu 18.04.01 ohne irgendwelche Eingriffe in die Bootparameter und das System arbeitete mit dem AMDGPU-Treiber. Btw. <klugschiss> Die CPU heißt Ryzen, der Grafikkern VEGA, Die APU CPU+GPU wollten sie früher einmal Raven nennen - heißt jetzt Ryzen x xxxxG </klugschiss> alterpinguin schrieb: ps. solche Bilder von "Grafikstörungen" sind mir übrigens schon von älterer Hardware bekannt, deshalb denke ich mir eigentlich nicht viel dabei und suche halt nach den passenden boot-Optionen und ob später ein besser passender Treiber installiert werden kann.
Jeep - das war bei mir auch immer so mit den APUs - oder auch bei den Grafikkernen im Chipsatz Grüße - und wir warten weiter... - oder verbauen einen Ryzen 5 2400G...
hi, k2-IT, dann mal hier der Auszug aus der Xorg.log mit den relevanten Zeilen was genutzt wird:
....
[ 32.782] (II) glamor: OpenGL accelerated X.org driver based.
[ 32.862] (II) glamor: EGL version 1.5 (DRI2):
[ 32.938] (II) AMDGPU(0): glamor detected, initialising EGL layer.
[ 32.938] (==) AMDGPU(0): TearFree property default: auto
[ 32.938] (II) AMDGPU(0): KMS Pageflipping: enabled
[ 32.939] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section
[ 32.939] (II) AMDGPU(0): Output DVI-D-0 has no monitor section
[ 32.939] (II) AMDGPU(0): Output DisplayPort-0 has no monitor section
[ 32.939] (II) AMDGPU(0): Output DisplayPort-1 has no monitor section
[ 32.951] (II) AMDGPU(0): EDID for output HDMI-A-0
[ 32.951] (II) AMDGPU(0): Manufacturer: ACR Model: 289 Serial#: 809585305
[ 32.951] (II) AMDGPU(0): Year: 2013 Week: 4
[ 32.951] (II) AMDGPU(0): EDID Version: 1.3
[ 32.951] (II) AMDGPU(0): Digital Display Input
[ 32.951] (II) AMDGPU(0): Max Image Size [cm]: horiz.: 53 vert.: 30
[ 32.951] (II) AMDGPU(0): Gamma: 2.20
[ 32.951] (II) AMDGPU(0): DPMS capabilities: StandBy Suspend
[ 32.951] (II) AMDGPU(0): Supported color encodings: RGB 4:4:4 YCrCb 4:4:4
[ 32.951] (II) AMDGPU(0): First detailed timing is preferred mode
[ 32.951] (II) AMDGPU(0): redX: 0.631 redY: 0.351 greenX: 0.334 greenY: 0.620
.... d.h. hier wird vom AMDGPU (Treiber) der Monitor erkannt, auch an welchem Port des mainboards der hängt (bei mir per hdmi-Kabel – und das ist auch der Punkt wo ich bei Lust+Gelegenheit mal mit 2 Monitoren testen wollte, schließlich sind da noch 2 Monitoranschlüsse von denen ich mal am Anfang den DVI-Port genutzt hatte) und was das für ein Monitor ist und wie der gesetzt wird (gamma etc.). Die anderen Xorg-Module werden wieder "entladen":
Codegrep -i unloading /var/log/Xorg.0.log
[ 32.952] (II) Unloading radeon
[ 32.952] (II) Unloading modesetting
[ 32.953] (II) Unloading fbdev
[ 32.953] (II) Unloading fbdevhw
[ 32.953] (II) Unloading vesa Dann noch zur komischen Namensvergabe der Grafikeinheit. Da wüsste ich gerne wo ich auf Anhieb sehen kann welcher firmware-blob geladen wird, denn in /lib/firmware/amdgpu gibt es kein Vega8. Deshalb meine ich bei mir wird das hier genutzt: dir /lib/firmware/amdgpu/rave*
-rw-r--r-- 1 root root 37376 Jul 6 12:18 /lib/firmware/amdgpu/raven_asd.bin
-rw-r--r-- 1 root root 9344 Jul 6 12:18 /lib/firmware/amdgpu/raven_ce.bin
-rw-r--r-- 1 root root 316 Jul 6 12:18 /lib/firmware/amdgpu/raven_gpu_info.bin
-rw-r--r-- 1 root root 17536 Jul 6 12:18 /lib/firmware/amdgpu/raven_me.bin
-rw-r--r-- 1 root root 268048 Jul 6 12:18 /lib/firmware/amdgpu/raven_mec2.bin
-rw-r--r-- 1 root root 268048 Jul 6 12:18 /lib/firmware/amdgpu/raven_mec.bin
-rw-r--r-- 1 root root 21632 Jul 6 12:18 /lib/firmware/amdgpu/raven_pfp.bin
-rw-r--r-- 1 root root 26948 Jul 6 12:18 /lib/firmware/amdgpu/raven_rlc.bin
-rw-r--r-- 1 root root 17408 Jul 6 12:18 /lib/firmware/amdgpu/raven_sdma.bin
-rw-r--r-- 1 root root 341728 Jul 6 12:18 /lib/firmware/amdgpu/raven_vcn.bin es gibt da firmware mit Namen vega10, vega12, vega20, aber eben nix mit vega8 und laut diversen Internetquellen (golem, phoronix..) soll das Ding "raven" genannt worden sein. lsmod zeigt übrigens auch, dass das kernelmodul amdgpu geladen ist und vom gpu_sched(uler) genutzt wird. Im kernel-module findet sich auch kein Texteintrag mit vega8. Nur eben vega10, vega12 und raven und ... der ganze andere Zoo etc.. Und Vega20 taucht erst im Modul vom 4.18er Kernel auf.
|
Sherminator
Anmeldungsdatum: 29. Mai 2006
Beiträge: 132
|
Hi, ich werfe mal meine zwei Cents in den Thread rein: Ich habe in der vergangenen Woche meinem Dad einen PC zusammengeschraubt und unter anderem einen AMD Ryzen 3 2200G auf ein MSI B350M PRO-VDH gebaut.
Dann habe ich mit ubuntu-18.04.1-desktop-amd64.iso installiert. Der erste Stolperstein war, dass der Ubuntu-Installer keine nutzbare Grafikdarstellung hingekriegt hat: Der Bildschirm war merkwürdig zweigeteilt und nach unten hin "verwischt". Deshalb habe ich im zweiten Versuch die Kernel-Option "nomodeset" mitgegeben, woraufhin die Installation klappte.
Im fertig installierten System wunderte ich mich dann über die schlechte Grafik-Performance* und lernte, dass die im Installer gewählte Kernel-Option in das installierte System übernommen wird. Also musste ich das in /etc/default/grub entfernen und die Änderung mittels update-grub an den Start bringen. Nach einem Neustart war die Grafik-Performance erwartungsgemäß (ich als Nicht-Gamer mit entsprechend bescheidenen Ansprüchen würde sogar sagen: Die Grafik-Performance ist überraschend gut). Nun läuft das System seit ein paar Tagen, und ich habe noch keine Hilferufe bekommen. ☺ Ich würde also vorsichtig annehmen, dass das soweit passt. Liebe Grüße Stephan *mein Grafik-Benchmark für Otto-Normal-PCs: Ich spiele in der nativen Bildschirm-Auflösung (in diesem Fall 1080p) "Big Buck Bunny" ab und erwarte Ruckelfreiheit. ☺
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
Sherminator schrieb: Hi, ich werfe mal meine zwei Cents in den Thread rein:
......
Im fertig installierten System wunderte ich mich dann über die schlechte Grafik-Performance* und lernte, dass die im Installer gewählte Kernel-Option in das installierte System übernommen wird. Also musste ich das in /etc/default/grub entfernen und die Änderung mittels update-grub an den Start bringen. Nach einem Neustart war die Grafik-Performance erwartungsgemäß (ich als Nicht-Gamer mit entsprechend bescheidenen Ansprüchen würde sogar sagen: Die Grafik-Performance ist überraschend gut).
...
hi,
prima, denn genau das hab ich in meiner Beschreibung vergessen. Die Option "nomodeset" um einen "sauberen Grafikbildschirm" hinzubekommen ist nur beim Ubuntu-Livesystem/Installationsystem notwendig. Später muss die wieder weg, wenn der "amdgpu"-Treiber installiert wurde und aktiv sein soll (der mag kein "nomodeset" und meckert dann auch entsprechend in den logs). Zu der Ansicht des "zerstörten Grafikbildschirms", war das wie in meinem oben verlinkten Bild (dem ersten von 6 Ubuntu-18.04-Installationsbildern)?
(das ist der Link von meinem posting oben:
https://media-cdn.ubuntu-de.org/forum/attachments/57/34/8998328-Ubuntu180401_a.jpg
) Ich habe in der
/etc/default/grub
den übernommenen Eintrag von der Installation leer gesetzt
und dort als Default Bootoption für alles mit Linux GRUB_CMDLINE_LINUX_DEFAULT gesetzt: -----
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
#GRUB_CMDLINE_LINUX="acpi=off noapic nomodeset"
GRUB_CMDLINE_LINUX_DEFAULT="noquiet nosplash iommu=soft"
#GRUB_CMDLINE_LINUX="nomodeset"
GRUB_CMDLINE_LINUX=""
.... Wer natürlich einen splash-screen haben will, der wird dort "quiet splash" schreiben. Danach natürlich, wie Du richtig schreibst, ein "update-grub". Und natürlich interessant, dass Du auch ein mainboard mit dem B350-Chipsatz hast, diesmal sogar von MSI. Leider immer noch niemand mit dem typischen Heise-PC-Bauvorschlag-mainboard, bei dem die vom Einsatz mit Linux abraten.
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
Ihr bringt das etwas durcheinander. Man kauft sich eine AMD APU nicht um ein Bild auf dem Monitor zu haben, sondern weil man diese hochwertige GPU 👍 nutzen möchte. 3D Anwendungen, OpenCL wie auch immer. ... und das klappt halt nicht. Ein Video Clip nutzt die GPU möglicherweise gar nicht. Das kannst du einfach mit mpv und dem Befehl "top" prüfen. Bei meiner ollen Nvidia liegt die CPU Last bei exakt 1% für den Ton. Warten auf 18.10! P.S. auch Spiele sind ein äußerst relativer Begriff.
|
alterpinguin
Anmeldungsdatum: 24. Mai 2014
Beiträge: 786
|
hakel schrieb: Ihr bringt das etwas durcheinander. Man kauft sich eine AMD APU nicht um ein Bild auf dem Monitor zu haben, sondern weil man diese hochwertige GPU 👍 nutzen möchte. 3D Anwendungen, OpenCL wie auch immer. ... und das klappt halt nicht. Ein Video Clip nutzt die GPU möglicherweise gar nicht. Das kannst du einfach mit mpv und dem Befehl "top" prüfen. Bei meiner ollen Nvidia liegt die CPU Last bei exakt 1% für den Ton. Warten auf 18.10! P.S. auch Spiele sind ein äußerst relativer Begriff.
sorry, aber Du liest diesen thread nicht richtig, denn sonst hättest Du das von mir verlinkte Bild mit 3D-Ausgabe von Quake gesehen und auch, dass ich deutlich darauf hingewiesen habe, dass ich sehr wohl 3D-Spiele wie doom-3 und auch quake-4 darauf laufen lassen. So einen screenshot kann ich natürlich auch nachliefern, aber ich glaube, dass das in Deinem Fall kaum hilft, so selbstverständlich ist Deine Ablehnung zu bemerken. Natürlich gibt es mittlerweile Spiele, die multithreading für die Grafikausgabe nutzen. Wenn ich aber 2, 3 Spiele mit entsprechender Grafikausgabe laufen lasse, dann ist das im Grunde ähnlich. Was ich demnächst noch probieren wollte ist eine Version von etxreal (neuere Fassung einer id-Engine) bei der z.B. die Spieleranimationen in der Grafikkarte berechnet werden. Übrigens, für die, die es auf dem screenshot nicht bemerkt haben, da wird auch die Audioausgabe simultan zusammengemixt (im screenshot von einem Musikplayer, prboom-engine, darkplaces-engine und video-Karte – wobei die CPU-Last nur auf einem core über 3GHz geht, was man da auch erkennen kann).
|
crazy-biscuit
Supporter
Anmeldungsdatum: 6. November 2010
Beiträge: 4844
|
@alterpinguin die Aussage von hakel richtete sich vermutlich eher an Sherminator. In diesem Fall stimmt: Es sind schon zweierlei Dinge, ob ein Video-Overlay funktioniert oder 3D. Davon ab: Ich denke so oder so emphielt es sich zur finalen Version von (X)Ubuntu 18.10 zu wechseln, da dann keine PPAs o.ä. mehr nötig sind. Oder aber man fährt bis 18.04.2 mit der PPA-Lösung, schmeißt die dann runter und nutzt HWE (mit Ubuntu 18.10-Kernel, also vermutlich Linux 4.18 - 4.19 wird bis zum Kernel-Freeze wohl nicht integriert werden können).
|
hakel
Anmeldungsdatum: 13. August 2009
Beiträge: 23336
|
https://wiki.ubuntuusers.de/Spiele/Quake4/
Quake 4 erschien im 4. Quartal 2005
gibt es mittlerweile Spiele, die multithreading für die Grafikausgabe
Aufgrund solcher Aussagen kann ich -ohne diese CPU zu besitzen- nur abraten!
in Deinem Fall kaum hilft, so selbstverständlich ist Deine Ablehnung zu bemerken.
"Ablehnung" hört sich so emotional an. Ich versuche nur, hier eine für Linuxanwender streßfreie Beratung zu machen. "G" wäre für mich der perfekte Allrounder. Preis/Leistung CPU und GPU. Das ist zutiefst frustrierend!
|