UMA Frame Buffer Size bei nicht vorhandener Bios Option einstellen

[maschinenbauer]

Hallo zusammen,

ich habe ein Notebook (CAPTIVA R66-730 = Clevo NL53NU) gekauft, welches leider offensichtlich keine Möglichkeit bietet, im Bios die UMA Frame Buffer Size einzustellen. Diese ist fix auf 512 MB eingestellt, was für mich den gewählten AMD-Prozessor sinnlos macht. Diesen hatte ich aufgrund der hohen Grafikleistung der iGP ausgewählt.

Ich habe schon diverse "Hotkeys", welche ich im Internet gefunden habe, ausprobiert, um mir mehr Optionen anzeigen zu lassen. Leider hat nichts funktioniert. Kenn jemand eine Möglichkeit beim Bios von Clevo Notebooks? Es weist ein UEFI von Insyde H2O mit grafischer Benutzeroberfläche (mit Cursor) auf.

Vom Support von Captiva habe ich kein Bios Update erhalten können. Ebenso erhalte ich kein Bios direkt von Clevo (dieses ist dort nur für Reseller, wie Captiva, zugänglich). Weiß jemand, wo ich ein Bios erhalten kann, welches diese Optionen bietet?

Der Support von Captiva hat mir gesagt, dass sich die Menge automatisch basierend auf der Anforderung einstellen soll. Da die Menge meines Wissens nur beim / vor dem Start des Bios und nicht zur Laufzeit des Betriebssystems definiert werden kann (das Reservieren von RAM durch Hardware ist meines Wissens nicht zur Laufzeit des Betriebssystems möglich, kann dies meines Wissens jedoch nur in der Form geschehen, dass das Betriebssystem dem Bios mitteilt, welche Menge beim nächsten Start genutzt werden soll. Ich habe schon Boot-Parameter des amdgpu-Treibers ausprobiert. Damit konnte ich die Menge nur reduzieren, aber nicht erhöhen. Kennt jemand eine Möglichkeit dies unter Linux zu ändern. Alternativ: Kennt jemand eine Möglichkeit dies unter Windows / FreeDOS dauerhaft zu ändern, d.h. so dass die neue VRAM-Menge auch nach einem Neustart mit Linux unverändert bleibt?

Leider benötige ich die Information recht zügig, da ich das Notebook, falls sich keine Lösung findet, nur noch bis Ende Dezember zurückgeben kann.

Vielen Dank im Voraus.

 

[BlubbsDE]

Der Support von Captiva hat mir gesagt, dass sich die Menge automatisch basierend auf der Anforderung einstellen soll. Da die Menge meines Wissens nur beim / vor dem Start des Bios und nicht zur Laufzeit des Betriebssystems definiert werden kann (das Reservieren von RAM durch Hardware ist meines Wissens nicht zur Laufzeit des Betriebssystems möglich, kann dies meines Wissens jedoch nur in der Form geschehen, dass das Betriebssystem dem Bios mitteilt, welche Menge beim nächsten Start genutzt werden soll.

Der Support hat recht. Die einstellbare VRAM Menge im Bios hat im Grunde nur noch Kompatibilitätsgründe. Bei aktuellen iGPUS / APUs wird der RAM dynamisch zugewiesen.

Das kannst Du doch einfach selbst nach gucken, in dem Du die GPU nutzt und Dir den VRAM Bedarf anschaust.

 

[maschinenbauer]

Ich habe dies gestern Abend erneut mit einem Linux Live System (Kubuntu 22.04) getestet. Diesmal habe ich zur Erzeugung von Grafiklast Minecraft mit einem 256 Pixel pro Textur auflösendem Texturepack gestartet. Dieses dürfte aufgrund der großen Texturen sehr viel VRAM benötigen. Sollte die Aussage der automatischen Anpassung stimmen, müsste dies eine Vergrößerung des VRAMs erwirken. Allerdings war dies in meinen Tests nicht der Fall. Stattdessen konnte ich im Systemmonitor feststellen, wie immer wieder die Grenze von 512 MB knapp erreicht wurde und es dann zu einem Einbruch in der VRAM-Kurve auf ca. 250 - 350 MB kam. Wie nicht anders erwartet überfordern die hochauflösenden Texturen die iGP etwas (es waren nur noch ca. 15 fps möglich. Dies kann aber nicht erklären, dass immer wieder die gesamte Benutzeroberfläche einfriert (Hinweis: KDE nutzt die Grafikkarte ebenfalls intensiv, sodass bereits direkt nach Systemstart ca. 400 MB VRAM genutzt werden). Dieses Einfrieren dauert mehrere Sekunden bis einige Minuten und endet teilweise erst mit einem Crash des Spiels. Ursächlich ist offensichtlich der VRAM und nicht der Systemspeicher (dieser war noch zu etwas mehr als 1 GB frei, Swap stand zur Verfügung, war aber so gut, wie ungenutzt). Offensichtlich wird der VRAM nicht dynamisch angepasst.

Daher die Frage: Wie kann ich bewirken, dass die Anpassung stattfindet?

 

[maschinenbauer]

Heute habe ich erneut einen Test durchgeführt. Eigentlich wollte ich nur die Performance mit einem größeren Modpack (ATM 6) testen. Die Performance war völlig ok. Bei Sichtweite 16 ca. 50 - 70 FPS und bei Sichtweite 32 immerhin noch 25-30 FPS. Die Werte wurden mit Standard-Grafikpaket (16x16 Pixel) auf einer bestehenden Karte innerhalb der Bebauung bei Sicht Richtung Horizont (nach unten / oben sind die Werte höher) ermittelt. Nach dem Beenden des Spiels kam dann die Überreschung. Der Befehl glxinfo -B ergab erstmalig eine Ausgabe, die darauf hindeutet, das zusätzlicher RAM für die iGP reserviert wurde:

glxinfo -B
    name of display: :0
    display: :0  screen: 0
    direct rendering: Yes
    Extended renderer info (GLX_MESA_query_renderer):
        Vendor: AMD (0x1002)
        Device: AMD RENOIR (LLVM 13.0.1, DRM 3.42, 5.15.0-43-generic) (0x164c)
        Version: 22.0.5
        Accelerated: yes
        Video memory: 512MB
        Unified memory: no
        Preferred profile: core (0x1)
        Max core profile version: 4.6
        Max compat profile version: 4.6
        Max GLES1 profile version: 1.1
        Max GLES[23] profile version: 3.2
    Memory info (GL_ATI_meminfo):
        VBO free memory - total: 80 MB, largest block: 80 MB
        VBO free aux. memory - total: 2301 MB, largest block: 2301 MB
        Texture free memory - total: 80 MB, largest block: 80 MB
        Texture free aux. memory - total: 2301 MB, largest block: 2301 MB
        Renderbuffer free memory - total: 80 MB, largest block: 80 MB
        Renderbuffer free aux. memory - total: 2301 MB, largest block: 2301 MB
    Memory info (GL_NVX_gpu_memory_info):
        Dedicated video memory: 512 MB
        Total available memory: 3584 MB
        Currently available dedicated video memory: 80 MB
    OpenGL vendor string: AMD
    OpenGL renderer string: AMD RENOIR (LLVM 13.0.1, DRM 3.42, 5.15.0-43-generic)
    OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.0.5
    OpenGL core profile shading language version string: 4.60
    OpenGL core profile context flags: (none)
    OpenGL core profile profile mask: core profile

    OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.0.5
    OpenGL shading language version string: 4.60
    OpenGL context flags: (none)
    OpenGL profile mask: compatibility profile

    OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.0.5
    OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

Unter Memory info (GL_ATI_meminfo) wiese die drei aux. Memory Zeilen zu meinem Erstaunen hohe Werte von ca. 2,3 GB auf. Offensichtlich handelt es sich bei diesen Werten um freien zusätzlichen Speicher. Auch wenn es zunächst nicht so aussah, hatte BlubbsDE doch recht. Bei meinen ersten Test vor Weihnachten wurde von der iGP offenbar zu wenig RAM benötigt, um eine Erweiterung zu triggern, bei meinen Tests vorgestern war die Menge des benötigten Systemspeichers hingegen offenbar zu hoch. Vermutlich konnten die knapp 1 GB freien Speichers nicht genutzt werden, da sie bereits mit noch im Cache gehaltenen Daten belegt waren (diese könnten theoretisch gelöscht werden). Leider ist dieser zusätzliche RAM im Systemmonitor nicht ersichtlich.

Folglich kann das Gerät bleiben, da es für meine Anforderungen taugt und ich kann das System installieren. Und wenn es dann doch irgendwann Probleme gibt, kann ich ja noch den RAM von 16 GB auf 32 GB aufrüsten. Vielen Dank noch einmal.