Dennism schreef op maandag 16 november 2020 @ 21:54:
@
DaniëlWW2 Die bios feature zie ik daar zo niet, wel dat het systeem in uefi mode moet staan qua bios en dus ook zo geïnstalleerd qua OS. Maar dat is tegenwoordig redelijk standaard, ik kom eigenlijk al jaren niet anders meer tegen.
Snap dat dramatische over die Windows herinstall ook niet echt, das tegenwoordig echt 15-20 min werk ofzo
Volgens het support document van MS heb je een driver nodig die het support en een vbios zo lijkt het. Opzich vind ik dat ook wel logisch, immers aangezien deze feature al minimaal een paar jaar in Windows zit, en schijnbaar in Linux al veel langer gebruikt wordt vind ik een moederbord bios update minder logisch, immers hoe werd anders van deze feature gebruikt gemaakt voor dat AMD er met deze kaarten wat meer ruchtbaarheid aan gaf, tenzij het voorheen expliciet uitgezet werd bij DiY zelfbouw oid.
Dat een feature in Windows en Linux al langer zit, wil niet zeggen dat deze wijdverspreid gebruikt wordt. Het wil ook zeker niet zeggen dat de genoemde BIOS-optie noodzakelijk is voor het gebruik van die feature.
Ik weet niet 100% precies hoe het werkt en ik heb vast kleine feitelijke foutjes in dit verhaal, maar ik kan me voorstellen dat het met geheugenadressering te maken heeft zoals dat een aantal jaren geleden ging. Toen was van alles en nog wat 32-bits, waarmee je tot 4GB geheugen kan adresseren. Het ging dan voornamelijk om software, maar zeker ook om hardware. Aangezien alle stukjes geheugen die je wilt kunnen adresseren adressen moeten hebben, moesten die dus in de adresruimte gemapt worden, en dat gebeurde dus "onder 4GB". De framebuffer zat daar ook bij. Die was doorgaans iets van 256MB maximaal dus dat maakte allemaal niet zo veel uit, gevolg was wel dat je op sommige configuraties eigenlijk effectief maar 3 tot 3.5GB RAM kon gebruiken omdat de rest van de adresruimte in gebruik was door andere hardware. De eerste PCIe-kaarten kwamen in 2004 uit, rond die tijd ook de eerste Athlon 64, maar toen was >90% van de systemen nog 32-bits dus was dit soort geschuif met geheugenadressering nog hard nodig.
In de daaropvolgende jaren is diezelfde "oude" PCIe gemeengoed gebleven maar de systemen zijn geleidelijk aan voor >99% 64-bits geworden. Juist vanwege dit geleidelijke was het nog erg belangrijk dat alles zoveel mogelijk gelijk bleef omdat er nog veel 32-bits software en hardware bestond welke alleen met 32-bits pointers konden werken, dus ondanks de toegenomen adresruimte (16EB vs 4GB) bleef het belangrijk dat alle peripherals nog steeds in dat onderste 4GB-blok adresseerbaar waren en moest daar bovendien minimaal ook een stuk RAM in adresseerbaar zijn. Voor het OS maakte het niet zoveel uit, Windows had bijvoorbeeld als default maar 2.3GB (meen ik) adresseerbaar voor 32-bits applicaties (onder 4GB dus), de rest van het geheugen werd hoger in de adresruimte beschikbaar gemaakt zodat 64-bits applicaties deze beperking niet hadden.
Fast forward naar nu, er is nog geen enorme noodzaak geweest (buiten miners kennelijk) om peripherals met grote geheugens integraal beschikbaar te maken in de adresruimte, dus het default op de meeste systemen is nog steeds dat die adressen onder 4GB zijn, wat dus direct ook de absoluut maximale grootte is (er gaat nog wat af omdat er vast meer dan 1 apparaat zo werkt). Voor de globale werking van een PC maakt dat helemaal niet uit, bijvoorbeeld het RAM kan prima vanaf het adres "8GB" ofzo geadresseerd worden in 1 groot doorlopend blok, zodat de hele onderste 0-4GB vrij is voor peripherals. Zoiets gebeurt dan ook. Zaken als een resizable BAR ("framebuffer") werken gewoon prima in deze opzet. Alleen is het verschil dat we nu een stapel 16GB-videokaarten hebben gekregen en dat gaat dus niet passen. Daarom is deze switch noodzakelijk om de feature volledig te kunnen gebruiken, anders zit je aan slechts een kwart daarvan vast, en in de praktijk waarschijnlijk nog iets minder. Ik kan me best voorstellen dat de driver in het slechtste geval dan zoiets heeft van "laat maar" en die feature niet gebruikt, in het beste geval werkt het wel maar met een performance-penalty.
Het nadeel van deze switch is dat 32-bits software zeker weten geen gebruik meer kan maken van die adresruimte. Systemen met een 32-bits OS die de framebuffer direct in software aanspreken zullen dus geen beeld meer kunnen laten zien. Maar ja, daar koop je geen Radeon 6xxx voor

Alleen weten de moederbordmakers dat niet, en is het het fijnst voor de veilige defaults om alles te laten werken zoals alle voorgaande generaties. Dan komen we weer terug op de feature zoals die al in Windows en Linux aanwezig is, deze is prima bruikbaar om de BAR te resizen van de default 256MB naar 2, 3 of zelfs 4GB, tenminste dat denk ik. Vanwege het legacy-aspect kan het zomaar zo zijn dat de adressering na het booten vast ligt als deze <4GB is, waardoor je alsnog die optie nodig hebt. Maar technisch is er geen beperking voor een grotere BAR zolang die maar in de 4GB-adresruimte past. Bijvoorbeeld videokaarten van een paar jaar geleden, met 2GB geheugen, zouden prima het hele geheugen direct adresseerbaar kunnen hebben.
Op nieuwere moederborden is het waarschijnlijker dat deze switch aanwezig is, wellicht is het zelfs een AGESA-setting waardoor het voor AMD makkelijk te valideren/garanderen is. Als oudere of Intel-hardware de adressering nog default onder 4GB doen en deze switch nog niet hebben, zal het beperkt werken of de driver kan kiezen om het dan maar helemaal niet te doen. Dan krijg je weer zeurende consumenten die de technische details niet kennen, dus dan is het voor AMD maar het beste om te zeggen van gebruik dit, dit en dit, dan garanderen wij het. Ik weet niet precies hoe ze het verwoord hebben, maar in ieder geval op X570 lijkt me dat er geen enkele technische beperking is voor Ryzen 3xxx-CPU's. Op mijn Aorus Master heb ik deze optie in ieder geval al bijna anderhalf jaar aan staan.
Alle eenheden hier zijn binary, dus MiB, GiB en EiB