Intel Arc Infos gesucht: Vulkan - reBAR Support nur auf Intel CPUs mit iGPU / kein reBAR auf AMD CPUs ?

[lynxx83]

Hallo,

Ich bin unlängst durch eigene Tests in Baldurs Gate 3 mit einer Arc A770 darauf gestoßen,

als ich mal genauer nachsehen wollte,
wieso BG3 leider so derart schlecht läuft - erstens viel schlechter als andere Spiele die ich auf der Arc bereits getestet hatte,


und was BG3 im speziellen betrifft,

gibt es ein Problem, mit unterschiedlichen Gesichtern -

sowohl unter DX11 (hier leider wie befürchtet) als auch Vulkan (hier hätte ich es nicht erwartet) :

Mikro Ruckler, oder Hänger / Stottern,

die aber je nach API bzw Spielszene unterschiedliche Charakteristik aufweisen.


auch hab ich mir dann die Tests von BG3 auf PCGH & CB genauer angesehen,
und die Arc performt tatsächlich in dem Titel schlechter als man sonst im Durchschnitt erwarten darf,

nämlich was den relativen Abstand bei BG zur Konkurrenz (etwa RX 6700 XT / RTX 4060 Ti) betrifft, sowohl bei Tests auf CB als auch PCGH..
der Rückstand wird bei zunehmender Auflösung dann sogar noch größer - sonst ist es ja oft umgekehrt,
und die Arc verkleinert in 1440p oder 4K ihren Rückstand fast jedes mal...
so steht dann die Arc - festgesetzt auf 100% - am Ende einer RX 6700 XT mit teils über 150% gegenüber,
und kann sich nicht mal merklich von der RX 6600 absetzen (immerhin noch 96% Leistung einer Arc),
und selbst von einer alten RX 5700 XT wird Arc einfach mal so überholt...

auch was avg fps und framtimes / avg lows betrifft, kann ich überhaupt nicht so einfach behaupten Vulkan wäre hier generell besser als DX11 (das ist es zwar oft scheint es, aber eben an anderen Stellen oft genug auch deutlich schlechter)

Schade, fand ich auch dass man sich weder auf CB noch PCGH die dritte Möglichkeit -nicht- angesehen hat,

denn einen klaren Gewinner gibt es dann auf die Frage "Vulkan oder DX11? " Dann nämlich doch:

Und die Antwort lautet zumindest für die Arc: " DXVK 2.2 ! "
und zwar sowas von deutlich.

(die meisten capframex Screenshots hatte ich im BG3 Benchmark test thread bereits gepostet, ein paar bin ich evtl schuldig geblieben)


Das soll hier aber vorrangig erst mal nicht Gegenstand der Diskussion sein,


Sondern vor allem erstmal folgender Umstand:

Intel Arc A770 : CapframeX meldet Resizable Bar für Vulkan: Off (256 MiB)
(Gigabyte X570S UD FW F6a , Arc A770, Treiber *.4644 und auch die letzten paar davor, Ryzen 5600)




alles was man im BIOS korrekt setzen muss bzw kann, hab ich auch so gemacht:

was GPU-Z dann aber im advanced tab für Vulkan anzeigt, erklärt wiederum wieso CapFrameX vermutlich gleich sagt: "reBAR nur teilweise" :

ich hatte bzw habe davon ja eigentlich immer noch null Ahnung,
zumindest aber hatte ich mich aber ein bisschen eingelesen, ein guter Artikel ist zB. folgender,

der zumindest grundlegendes übersichtlich und (für mich zumindest beinahe ) sehr verständlich zusammenfasst:

Vulkan Memory Types on PC and How to Use Them

nach allem was ich nun also zu reBAR und aktuellen Windows Vulkan Treiber sowohl von AMD als auch Nvidia gelesen hatte,

war das eher ziemlich unerwartet, der Speicher bzw Memory Heap / Memory Type mit sowoh Device_local_bit als auch host_visible_bit beträgt nun mal nur ~256MB, wie's zB bei AMD früher mal war.

Hier noch die Übersicht was das eigene Vulkan Hardware Caps viewer Tool anzeigt:

• AMD Ryzen 5600
• Gigabyte X570S UD FW F6a (rBAR im UEFI an & laut Arc Control / GPU-Z rebar tab aktiv, siehe oben)
• Intel Arc A770 16GB VRAM (Treiber *.4644 aktuell und die letzten 2-5 Treiber davor)
• 32GB DDR4 System RAM
• Windows 10

Jedenfalls bin ich eben skeptisch geworden ob hier alles optimal läuft,

und hab natürlich auch direkt nach dem vom CapframeX gemeldeten rBAR Status für die Arc & Vulkan im Netz gesucht und zusätzlich noch dies gefunden:
https://www.reddit.com/r/IntelArc/comments/13ycjpf/intel_arc_owners_vulkan_resizeable_bar_check/

tl;dr - You need to have an Intel processor with integrated graphics enabled and running for ReBAR to be on in Vulkan (as it stands right now)

https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/issues/330

Partial implementation of ResizeBAR in Arc?

Ich habe daraufhin bereits im BG3 Benchmark thread zum Test von @Wolfgang und @AbstaubBaer darauf hingewiesen bzw in die Runde gefragt, (https://www.computerbase.de/forum/t...lly-im-benchmark.2155255/page-8#post-28477965 & https://www.computerbase.de/forum/t...lly-im-benchmark.2155255/page-9#post-28478291 ) leider ist es wohl unter gegangen und hatte keinerlei Beachtung gefunden;


daher hier an dieser Stelle nochmal:

was meldet euch CapframeX , GPU-Z advanced tab,

oder der Vulkan Hardware Capabilites Viewer ?

Wer hat eine Arc dGPU , und bekommt reBAR für Vulkan als "on" gemeldet statt "off",
in der vollen Größe - anstatt 256MB - entsprechend dem gesamten Vram der Karte ?

Und welche CPU habt ihr in dem Fall verbaut?


Vielen Dank für die Mithilfe.
wenn sich diesmal wenigstens drei Leute melden, würde ich mich schon sehr freuen.

LG. L

 

[konkretor]

rBAR hängt vom Mainboard ab und ohne rBAR ist die ARC leider nicht zu gerbauchen.
Du hast leider nicht geschrieben welches Mainboard mit welcher UEFI Version du da im Einsatz hast.

Welche Treiber Version nimmst du denn für die Arc?
Ich kann morgen mal nach schauen ob das bei mir auch so ist.

 

[cvzone]

Generell scheint es ja gemäß Screenshot aktiv zu sein, nur eben nicht unter Vulkan.

Wie man bei Nvidia sehr gut sehen kann, ist es in erster Linie dann auch eine Sachen des Treibers (Whitelist), selbst wenn es das Mainboard kann.

So sieht das Ganze bei meiner 6900XT unter Vulkan aus

 

[lynxx83]

rBAR hängt vom Mainboard ab und ohne rBAR ist die ARC leider nicht zu gerbauchen.
Du hast leider nicht geschrieben welches Mainboard mit welcher UEFI Version du da im Einsatz hast.

Welche Treiber Version nimmst du denn für die Arc?
Ich kann morgen mal nach schauen ob das bei mir auch so ist.

..das hatte ich nicht extra erwähnt das stimmt. wie auf dem GPU-Z screenshot zu sehen ist,

sind die entsprechenden Einträge im Bios aber scheinbar richtig gesetzt.

reBAR ist ja auch "an" , wie etwa das eigene Arc Control, capframex oder gpu-z vermeldet,
und funktioniert soweit auch messbar (wenn ich es im bios an/aus stelle und einen beliebigen Titel vorher/nachher benche).

nur eben für Vulkan ist es "merkwürdig" was sämtliche Tools auslesen,

und was der VulkanCapsViewer, das GPU-Z advanced tab, und eben capframex dazu anzeigt.

Arc Treiber ist der aktuelle 4644er , dass mir reBAR speziell für Vulkan aber als "off" bzw partiell angzeigt wird, war auch schon in den letzten versionen davor so.

Es schien mir hier nebensächlich zu sein, weil der Unterschied was man angezeigt bekommt scheinbar in der CPU liegt, wenn die bisherigen Berichte bzw dürftigen Infos stimmen.

Es handelt sich um ein Gigabyte X570S UD mit Bios FW F6a derzeit (ich weiß es gibt seit kurzem eine neuere (F6b).. werd ich mal versuchen am WE ) glaube kaum dass es nochmal nen Unterschied machen wird aber wer weiß.

hab die Infos dem Startpost oben hinzugefügt.

 

[Verak Drezzt]

@lynxx83 die Leistung der ARC Treiber sind eine Wundertüte, unter 3060 bis 3070 Leistung alles dabei, davon ab das manche Titel so gut wie überhaupt nicht laufen, mal ganz abgesehen, sollte man aber wissen wenn man sich ausführlich mit der Karte beschäftigt hat

und ja ohne rBar ist die Karte noch weniger zu gebrauchen, sollte aber egal ob Intel oder AMD Plattform, wenn nicht zu alt, auch unterstützt werden

Ergänzung (25. August 2023)

@lynxx83 davon ab, eine A750 ist übrigens kaum langsamer und beide sind im Grunde FullHD Karten, die 16GB Version ist zum zocken völlig überdimensioniert

 

[lynxx83]

@konkretor

Ich kann morgen mal nach schauen ob das bei mir auch so ist.

danke, würd mich freuen, bin gespannt.


@Verak Drezzt das ist nur nichts was ich nicht weiß, suche, oder worauf ich hinaus wollte, aber danke.

@cvzone yepp, genau darauf wollte ich hinaus.. wieso melden alle tools dass zwar reBAR "an" ist, aber eben nicht "vollständig" bzw für Vulkan "off" ,
bzw limitiert auf die 256mb und nicht den gesamten vram Bereich..

und wieso sehen Leute mit Intel CPUs bzw um genauer zu sein mit CPUs mit iGPU dann scheinbar an den Stellen was anderes , für die Arc.

 

[Schrotti]

Ich habe im Zweitsys eine ARC770 mit 16 GB und schau morgen auch mal nach.

 

[Ray519]

ReBar und was via Vulkan API bereitgestellt wird sind getrennte Dinge.

ReBar ist ja eigentlich erstmal nur für den Treiber da.

Ja, meine 3090 hat ihren Speicher mit ReBar als Device-Local, Host-Visible und Host-Coherent getaggt, Entwickler können also mit der Vulkan API manuell den gesamten VRAM addressieren (nutzen kannst du das eh nicht so einfach, sonst könntest du ja die gesamte GPU zum Absturz bringen. Da muss schon trotzdem noch ein Treiber dazwischen sein und schauen "die Addresse gehört zu einem anderen Prozess, die darfst du weder auslesen noch beschreiben!".

Aber wir wissen ja von Nvidia, dass bloß weil ReBar an ist, das nicht von einem Spiel auch genutzt werden muss. Je nach Whitelist nutzen Spiele das klassische Verfahren um Daten in die GPU zu bekommen, weil beides Vor- und Nachteile hat und es auf die Anwendung ankommt, was davon jeweils überwiegt.

Die Frage wäre jetzt nur, muss in Vulkan eine Anwendung den "ReBar" Fall und den "nicht-ReBar" beide im Code vorsehen und der Treiber sagt der Anwendung dann welcher davon benutzt werden kann? Das glaube ich nicht.
Ich würde davon ausgehen, dass das genau wie beim Rest auch ist: du sagst der API welche Daten für die GPU sind, das wird letztendlich dem Treiber übergeben. Und der macht dann damit entweder das was ReBar erfordert, oder eben das alte Verfahren. Und während man mit ReBar der API auch Fähigkeiten einräumen könnte, dir nur mit ReBar gehen, glaube ich nicht dass das notwendig ist, um Haupt-Vorteile aus ReBar zu ziehen.
Schließlich haben wir bisher noch nie davon erzählt bekommen, dass ein Spiel etwas besonderes tun muss, um ReBar nutzen zu können. Das wurde immer nur als Treiber-Intern gehandelt.

Aber hier bräuchten wir jetzt einen Vulkan Experten, um zu beurteilen ob dieser Unterschied überhaupt irgendwelche praktischen Einschränkungen hat für Spiele oder nebensächlich ist...

Und falls wir einen Vulkan-Experten auftreiben können, wären die nächsten Fragen: was sind denn Use-Cases für diese direkte Addressierung? Ist das wirklich dazu da, mit normalen Copy-Primitiven anstatt Vulkan-Copy-Primitiven Daten von und zur GPU zu kopieren? Muss man den Speicher vorher explizit in den eigenen Prozess mappen? Ist das eh nur, falls man vollständig exklusiven Zugriff auf die GPU hat? Oder ist das eigentlich nur eine informative Beschreibung der Eigenschaften der GPU aber eigentlich völlig unabhängig davon, wie man im Programm damit umgehen würde, weil eh alles abstrahiert und hinter Handeln versteckt ist? Gerade damit der Treiber die Kontrolle hat und zB Sicherheitschecks ausführen könnte.

Ergänzung (25. August 2023)

Nachdem ich den ersten verlinkten Blog-Beitrag durchgelesen habe, kann ich mir ein paar meiner Fragen selbst beantworten:

• Use-Case: Ja tatsächlich um Datentransfers mit normalen Copy-Primitiven zu micromanagen. Das kann also ein paar Instruktionen sparen, gegenüber der abstrakteren Methode die ich gewohnt bin. Und geht genau nur wenn der Speicher auch als DeviceLocal und HostVisible bereitgestellt wird
• Ja, wird explizit gemappt, damit beim Mappen die Sicherheit berücksichtigt werden kann. Schon faszinierend das Vulkan hier die Errungenschaft der virtuellen Speicheraddressen mal direkt über Board wirft für ein paar Takte an Geschwindigkeitszuwachs
• Es ist zu einem gewissen Grad informativ. Es gibt Vulkan-Copy primitive, die dann den Treiber machen lassen, was auch immer der Treiber für das beste hält, um Daten von einem Speicher in den anderen zu bekommen. Da drin können immer noch die Vorteile von ReBar genutzt werden, wenn der Treiber das möchte, genau wie in allen anderen Fällen.
• Es ist möglich dass es gar keinen Speicher gibt der sowohl Host-Visible als auch Device-Local ist und das müssen Anwendungen auch können, die nicht einfach auf älterer Hardware / Software brutalst crashen sollen

TL;DR; das nicht der vollständige Device Memory Host-Visible ist, könnte dazu führen, dass Anwendungen, die dafür geschrieben wurden, nur mit ReBar oder auf iGPUs zu laufen gar nicht gehen würden.
Viel wahrscheinlicher: es könnte zu kleineren Geschwindigkeitsnachteilen führen bei Anwendungen, die manuelle Optimierungen in Vulkan für den ReBar Fall drin haben.
Es wird vermutlich keinen Unterschied machen, wenn die Anwendung für den "kleinesten gemeinsamen Nenner" geschrieben wurde. Die Entwickler also versuchen nur einen einzigen Weg vorzusehen, der für alles klappt. Denn dann würde dieser Device-Local, Host-Visible Memory eh nicht so genutzt.

Wie viele Spiele mit Vulkan Support die Vorteile nutzen könnten (also den Fall vorsehen) weiß ich überhaupt nicht...

 

[perkyagnostic]

Bei mir sieht es mit A770, B660 Aorus Master DDR4 und i5-13600KF (also ebenfalls keine iGPU) in GPU-Z genauso aus wie bei dir, bei Memory 4 steht auch 256 MB.

Sehr interessant das ganze und vor allem ärgerlich wenn es stimmt. Mit Intel Arc erlebt man immer wieder was neues.. aber ist ja nicht so als hätte ich nicht gewusst worauf ich mich da einlasse

Auch wieder geil wie hier von manchen Leuten wild drauf los geschrieben wird ohne zumindest zu versuchen den Ausgangspost zu verstehen..

 

[AbstaubBaer]

Ich habe daraufhin bereits im BG3 Benchmark thread zum Test von @Wolfgang und @AbstaubBaer darauf hingewiesen bzw in die Runde gefragt, (https://www.computerbase.de/forum/t...-spiele-hit-2023.2155255/page-8#post-28477965 & https://www.computerbase.de/forum/t...-spiele-hit-2023.2155255/page-9#post-28478291 ) leider ist es wohl unter gegangen und hatte keinerlei Beachtung gefunden;


daher hier an dieser Stelle nochmal:

was meldet euch CapframeX , GPU-Z advanced tab,

oder der Vulkan Hardware Capabilites Viewer ?

Ich bin für Technik der falsche Ansprechpartner. Habe @Wolfgang, gerade auf Gamescom, dazu angehauen:

"Muss ich mal schauen, in wie weit ich die nächsten 2 Wochen jetzt dazu komme, mir das mal anzuschauen. Aber könnte schon gut sein, dass es das ist."

 

[lynxx83]

@AbstaubBaer Danke, ich persönlich glaube ja nicht, dass diese Sache mit "vulkan reBAR 256mb" für das schlechte Abschneiden der Arc in BG3 verantwortlich ist,
Aber wer weiß es wirklich?

Ich rätsel halt jetzt grade erst mal was Arc und deren Treiber betrifft bzw übliche Tools, dass da nun was ganz anderes zu stehen scheint für rebar Vulkan,
je nachdem ob zb. eine amd cpu ohne igpu,
Oder eine intel gpu mit igpu dabei ist .

Ps: was BG3 betrifft, der teils krasse Unterschied zwischen "Vulkan" und "dx11 mit dxvk2.2" bei frametimes / min fps low hat mich erstaunt,
Die Arc mit Dxvk läuft gleich nochmal deutlich "runder" damit hier
(ps: hab nur ne ryzen 5600 hier, evtl hängt es bereits damit zusammen.. wie sieht's auf high end cpus aus, Vulkan vs dxvk?)

Das wäre dann vielleicht eher was für euch

Lg j

 

[Ray519]

je nachdem ob zb. eine amd cpu ohne igpu,
Oder eine intel gpu mit igpu dabei ist .

Hast du schon iwo die Memory Angaben von einer Arc GPU gesehen wenn eine Intel iGPU vorhanden ist?
Ich würde ja raten, dass CapFrameX einfach nicht sauber trennt zwischen mehreren GPUs. Und wenn eine halt gemeinsamen Speicher in Vulkan anbietet nicht hinterfragt, ob das nur eine der beiden GPUs ist...

 

[lynxx83]

..so ähnlich stelle ich mir es auch vor;

die genauen details von einem system mit intel cpu + igpu ,
was dort beim gpu-z advanced tab steht bzw noch ein bisschen besser im Vulkan Hardware Caps Viewer,
Wenn die igpu an ist, aber tatsächlich die dgpu angewählt ist - das hab ich bisher noch nicht.

Im GitHub intel comm bugtracker gibt es nur den Screenshot von capframex,
mit intel cpu & igpu & Arc steht da dann grün "on" statt rot "off",

@cvzone .. welche CPU hast du eigentlich
bzw wieviel system RAM ist verbaut?

ändert sich bei dir was an dieser Auflistung, wenn du bei gpu-z die iGPU statt der radeon rx auswählst?

ich glaube, der Vulkan hardware caps Viewer würde es evtl etwas genauer bzw übersichtlicher anzeigen, was da vielleicht was ist.. jedenfalls ist bei dir ja device local & host visible gleich mehrmals drin...

 

[cvzone]

welche CPU hast du eigentlich
bzw wieviel system RAM ist verbaut?

5900X mit 64GB - eine iGPU ist da nicht verbaut.

 

[Ray519]

ändert sich bei dir was an dieser Auflistung, wenn du bei gpu-z die iGPU statt der radeon rx auswählst?

die Speicher sind schon vollständig getrennt nach Device. GPU-Z klopft nur Memory Heap and Memory Type flach.

Fyi, das ist reproduzierbar mit meinem Intel 10750H + GTX 1650 TI (ohne ReBar). CapFrameX zeigt das Vulkan ReBar: on an, obwohl HW ReBar: off ist. Und die Speichermenge an der es das festzumachen scheint, ist schlicht der dynamische Speicher der iGPU.

Also CapFrameX scheint einfach zu schauen ob ein Speicher größer als der GPU Speicher Device-Local und Host-Visible ist oder so und trennt dabei nicht nach GPU.

Vulkan ReBar und DRD ReBar sind einfach nicht passende namen für das. Das ist ja mehr: gesamter GPU Speicher direkt addressierbar durch D3D/Vulkan. Deshalb wird ja auch die Speichergröße mit angegeben. Dann wäre es auch offensichtlicher, dass die Antwort fragwürdig ist bei mehreren GPUs.
Genau wie die ganze andere Verwirrung um ReBar. Das Feature erlaubt nur dem OS/Treiber nachträglich eine andere Menge an VRAM zu mappen / PCIe Mappings zu ändern. Aber den gesamten GPU Speicher in den CPU Addressraum zu mappen braucht auch kein ReBar, wenn man das nicht aus Kompatibilitätsgründen erst nachträglich im OS machen will.

 

[Schrotti]

@lynxx83
Schaut bei mir genauso aus wie bei dir im Posting 1.

 

[konkretor]

Bei mir sieht das so aus
Bin mit dem Arc Treiber etwas hinterher, aktuell läuft alles was ich spiele und sehe daher keine Notwendigkeit den Treiber zu wechseln.