AMD stopt ondersteuning voor 32bit-Radeon-drivers

Radeon Software Adrenalin 18.9.3 WHQL zal de laatste driverversie zijn die AMD nog met 32bit-ondersteuning uitbrengt. Wie nog een 32bit-versie van Windows draait, zal niet van latere drivers gebruik kunnen maken.

De ondersteuning van Radeon-software voor 32bit-Windows is in legacymodus gezet, meldt AMD aan het Japanse 4Gamer in antwoord op vragen hierover. "We zijn niet van plan 32bit-Windows in toekomstige driverreleases te ondersteunen", aldus het bedrijf.

AMD raadt aan te overwegen op 64bit-Windows over te stappen, maar meldt ook dat gebruikers hun huidige 32bit-drivers kunnen blijven gebruiken als ze dat willen. Van Radeon Software Adrenalin 18.9.3 WHQL zijn nog wel 32bit-versies beschikbaar, maar bij de RX Vega staan alleen 64bit-versies, constateert VideoCardz.

Nvidia kondigde in december vorig jaar aan te stoppen met 32bit-drivers.

Reacties (97)

Aangezien 32bit in Windows je maar 3.5GB RAM laat gebruiken is het ook niet zo vreemd dat ze er mee stoppen. Iedereen die een beetje wil gamen zit toch wel op 64bit tegenwoordig. Zonde om hier nog tijd in te steken.

… wat overigens een opzettelijke beperking van Windows is. Windows XP had met PAE gewoon support voor meer geheugen. IIRC was het destijds nVidia die het niet voor elkaar kreeg om dat stabiel te krijgen in videodrivers, en daarom heeft Microsoft dat nooit verder voor home en professional edities doorgevoerd.
Zelf heb nog 32-bit Windows Vista Professional met een hack (een dll vervangen of patchen iirc) met 8GiB RAM gebruikt. Werkte probleemloos. Nota bene met een nVidia-kaart. Een process zelf was wel nog beperkt tot maximaal 4GiB.

Dat je meer geheugen kunt toewijzen aan een CPU, wil niet zeggen dat een 32bit cpu meer dan 2GB aan een process kan koppelen, dat is technisch niet mogelijk ivm de addressering van het geheugen. De meeste games draaien met 1 proces meerdere threads. De 32 bit architectuur had nog wat gerekt kunnen worden als men meerdere processen meerdere threads had laten pakken.. maar met 64bit cpu's, is er geen noodzaak. en dat programmeert wel zo makkelijk. Wel balen als je nog een 32bit cpu hebt, en een recente radeon... maar dat zullen er nog weinig zijn... dan heb je x jaar geleden je cpu voor het laatst geupgrade.. logisch dat ze het droppen...

Tja als ik nog games speel zijn dat grotendeels oudere, dus 32-bit en zelfs 16-bit games. Hoewel ik Civilization 5 heb liggen vind ik SMAC en Civ 2 gewoon veel leuker.

Andere IL2 Sturmovik, The Elder Scrolls gcollein mijn collectie: 3 Morrowind (alle addons), Cossacks European Wars en als kers op de taart: Shattered Steel, qua gameplay nooit overtroffen.

En die werken vrijwel allemaal niet op 64-bits Windows.

Maar dan zal dat ook draaien met de 'oude' drivers toch.. ? Je hoeft niet persee de laatste te hebben..

Misschien wel, maar misschien ook niet omdat de oude drivers misschien niet meer compatible zijn met nieuwere hardware. Ik heb in deze slechte ervaringen met een Soundblaster kaartje en met drivers voor de All-in-Wonder Radeon 8500 die opeens jaren lang niet meer beschikbaar waren en nadat mijn kaart uiteindelijk de geest had gegeven opeens weer wel beschikbaar waren (ergens 2012 of zo).

Dat is prima mogelijk, maar het OS moet het wel beschikbaar maken. Dat is dan wel redelijk complex, zeker om dat veilig te doen, maar niet onmogelijk. Er zijn genoeg 'hobby' OS-en die 32-bit zijn maar 64-bit aan geheugenaddressering aan kan. Inclusief processen. Zie: https://wiki.osdev.org/PAE

PAE was ook beperkt tot 4GB.

Per process ja. Het OS heeft de beschikking over maximaal 64GiB. Bij Windows was dat alleen voor de server-versies, bij Linux is er uiteraard geen commerciële beperking en is die 64GiB te gebruiken.

4 simultaan adresseerbare GB is een inherente beperking van 32 bit.
PAE was/is een truuk om er voor te zorgen dat elk proces individueel 4gb aan kon spreken.
Dus in plaats van 4gb te moeten verdelen over alle processen inc os kon je met PAE 4 gb aan een programma toewijzen.
Ik heb bijvoorbeeld SQL Servers gedraaid met PAE en dat was marginaal effectief maaaaar er zaten ook massive nadelen aan. Elke communicatie naar een ander proces moest dan via swap dus hdd lopen. Bij SQL Server was dat niet zo'n probleem want eigenlijk een zelfcontained OS in disk management maar voor een spel is dit waardeloos. Drivers aanspreken... of via disk of drivers in spel memory space opnemen en omdat die totaal dan no gsteeds gecapped is op 4 gb heb je bijna geen winst.

PAE was een hack/truuk voor heel speciale cases, als het echt een panacea was zouden we ook geen 64bit telefoons nodig hebben (om maar een dwarsdoorsnede te noemen)

Ja met Windows, linux kan gewoon 64 GB aanspreken.
Ook de AMD driver zal gewoon updates krijgen onder Linux, ook voor oudere kaarten.

[Reactie gewijzigd door Soldaatje op 26 oktober 2018 02:14]

64GB per applicatie of in zijn geheel?

In zijn geheel: https://en.wikipedia.org/wiki/Physical_Address_Extension

Met 32-bit adres pointers is geen 64GiB aan te spreken. Het maximale bereik is 2^32 = 4GiB.
Het is m.i. technisch onmogelijk wat je zegt. Heb je een bron/bewijs?

Maar zo langzamerhand zullen 32-bit OS versies toch wel een zeldzaamheid worden?

[Reactie gewijzigd door kdekker op 26 oktober 2018 10:16]

Met PAE had Windows XP standaard ook maar 4 GiB beschikbaar overigens (in plaats van de 2 GiB die normaal beschikbaar was). Hiervan gaat nog wel wat af want je wil ook nog wel wat andere dingen rechtstreeks kunnen adresseren, zoals de videokaart grappig genoeg. Natuurlijk is met 32 bit 4 GiB sowieso het maximum wat je direct kan adresseren natuurlijk: 2^32 = 4Gi.

Maar goed, meer kan inderdaad wel; dat het niet goed is voor de performance en niet makkelijk voor de ontwikkeling van o.a. games lijkt me aan de andere kant ook evident.

32bit kan meer geheugen adresseren dan 4gb. Windows 2003 32bit Enterprise en Datacenter kunnen 64gb aanspreken. Het ding is alleen, het OS ziet de 64gb wel, maar een applicatie niet meer dan 4gb.

Er was zelfs een "patch" voor 32-bit XP (stukje code van 2003 Server) waarmee ook XP gewoon tot 64GB kon gaan. Heb ik nog een tijdje mee gedraaid.

Dat is bank swapping dat dan gebruikt wordt, hij wisselt dan blokken geheugen af die worden gekoppeld worden. Als bank A aan de cpu gekoppeld zit, kan die niks 'zien' in banb B, etc... performance technisch niet ideaal..maar het kon inderdaad wel. Maar dankzij de 64cpu / os ondersteuning niet meer nodig.

PAE is niet te vergelijken met bank switching. PAE maakt de size van het fysieke adres in de page table groter zodat je virtuele address space verder kan mappen in het fysieke dan de 32-bit beperking, zonder performance hit. Virtuele address space blijft wel altijd 32-bit.

XP had een softwarematige beperking daarop, Windows Server niet. De patch waar @cybermaus over praat haalt die beperking eruit.

Tsja, zo was 640KiB in plaats van 1MiB een opzettelijke beperking van de PC-architectuur in combinatie met DOS. Die dingen gebeuren nou eenmaal aan de bovenrand van wat technisch met de betreffende combinatie haalbaar is. 8GiB geheugen op een 32-bits processor, kan opzich wel. Je kon ook best boven de 1MiB op een ouderwetse PC, maar er komt het nodige kunst en vliegwerk bij kijken.

Serieus, opzettelijk beperking?
Het was opzettelijk gedaan maar niet om te beperken. Omdat men ten tijde van programmeren van het OS dacht dat dat meer dan genoeg zou zijn.

Ja serieus, opzettelijk en een beperking, precies zoals jij ook zegt. Over de achterliggende redenen heb ik nooit wat gemeld. Jouw reden is ook maar de helft. Het was technisch makkelijker EN men dacht dat het genoeg zou zijn.

Maar je levert er wel weer performantie voor in. Het is nu niet alsof Nvidia de macht had om MS hier in tegen te houden. Als het zo eenvoudig en probleemloos werkte had MS het gewoon aangezet.

Performantie?

Prestaties

Dat is Vlaams voor snelheid (of performance)

Staat anders wel gewoon in het groene boekje, dus is gewoon Nederlands hoor.

Ja, maar het betekent wat anders dan hier bedoeld wordt

Als Vlaming vind ik het anders een draak van een anglicisme. Het juiste woord in het Nederlands (ook in België ) is 'prestaties'.

Hou alsjeblieft op met 'Vlaams' als taal te positioneren want dat is het niet. De 'Vlaamse' dialecten die er nog zijn verstaat de gemiddelde Vlaming niet; want die worden in de Westhoek gesproken. Vergelijk het met Belgen: die praten ook geen Belgisch .

Nederlands is de standaardtaal in Vlaanderen, het is niet omdat onze accenten en woordenschat vaak afwijken dat dat ineens niet meer zo is. Met je lokale dialect maak je je aan de andere kant van het land niet verstaanbaar. Leg je erbij neer.

[Reactie gewijzigd door Borromini op 26 oktober 2018 00:46]

't is IT - technologie gerelateerd, dus zo raar is dat anglicisme nu ook niet hee. En sinds wanneer wordt er alleen in de Westhoek van België dialect gesproken ? Dialecten zijn er overal ter wereld.

Denk dat Borromini doelt op de "Vlaamse" dialecten. Als Nederlander uit het westen van het land kijk ik tegenwoordig wel uit om het over Holland te hebben want dan krijg ik het halve land over me heen. Wat dat betreft vind ik het best apart dat er in heel Nederlandstalig Belgie "Vlaams" gesproken zou worden terwijl West- en Oost-Vlaanderen maar een stukje van heel het taalgebied in Belgie zijn, en een minderheid volgens mij als het om bevolkingsaantallen gaat. Spreekt een Antwerpenaar bijv wel "Vlaams"? Een Limburger uit Nederland spreekt absoluut geen Hollands. Als je dat zegt dan gaan ze zo ongeveer door het dak. Kan me niet voorstellen dat dat anders is voor een Belgische Limburger als je zegt dat hij of zij Vlaams spreekt..

Woorden als "performantie" krijg ik overgens wel kromme tenen van zo lelijk vind ik het. Gebruik gewoon het Engelse woord of het aloude Nederlandse "prestatie". Op deze manier kun je alle Engelse woorden wel vernederlandsen maar daar zitten de meeste mensen niet op te wachten vermoed ik. Het getuigt in ieder geval van weinig creativiteit.

[Reactie gewijzigd door Anoniem: 1092407 op 26 oktober 2018 05:10]

Zou je denken. Recent nog eens naar gekeken en de games bleven eigenlijk allemaal hangen rond de maximaal 2500 MB ram geheugen. De truuk is dat het grootste deel van het geheugen gebruik uit textures bestaat en die zitten tegenwoordig in de vele Gigabytes op je videokaart. Ga zelf maar na, vroeger had je 4GB ram en een 1 GB vram. Tegenwoordig heb je in een vergelijkbaar segement 16 GB ram en 8 GB vram. Mocht iemand een game hebben die wel meer ram verbruikt dan hoor ik dat graag, ik kon er geen vinden.

Natuurlijk moet je om te gamen wel de maximale limiet per applicatie verhogen, dat was vroeger standaard 1 GB maar kon met een registry setting (op vista/win7) verhoogd worden naar 3 GB.

Met maximaal 2.5GB hou je nog 1GB over voor het OS en de rest, dat is erg krap.

Zelf zit in in Windows zo rond de 3GB en ga ik gamen gaat dat naar zo'n 6GB of 7GB afhankelijk van het spel. Ik zeg wel vaker dat meer dan 8GB voor gamen meestal niet nodig is, maar 4GB moet wel problemen geven. Iedere keer ieder programma moeten sluiten om maar net voldoende te hebben schiet ook niet op.

Je moet je niet blindstaren op de 3GB die Windows "gebruik".
Mijn pc op het werk heeft 24GB ram en die gebruikt +/- 6-7GB ram als die net is opgestart.
Mijn rommel pc thuis heeft 4GB ram en die gebruikt +/- 1,5 GB ram als die net is opgestart.

Mn 128gb systeem verbuikt maar 4 wanneer opgestart, heb je wel wat op achtergrond aan staan,
Maar met je punt heb je meer dan gelijk, wat je OS verbruikt is totaal niet intresant

klopt, wat hij niet direct nodig heeft, gooit ie in vitual mem (disk) , en als ie meer geheugen heeft, zal hij daar minder gebruik van maken, en vlotter reageren..

Vroeger was het verschil tussen ram en die enkele MB/s op kleine bestandjes op je harde schijf natuurlijk een extreem verschil. Alleen anno 2018 met een NVME SSD die dik 3000 MB/s doet merk je maar weinig van hetgeen in het ram als extra blijft hangen.

Het is al wel sneller, maar nog steeds vele malen trager als je ram geheugen...

Kwantificeer dat eens want met een moderne cpu + (NVME) ssd start vrijwel elk stuk stoftware extreem snel op. Voor zaken als Word, Pain, enz bestaan eigenlijk al geen wachttijden. Photoshop vanaf cold boot zit op een seconde of 6. Dat zit op dat moment allemaal nog niet in je ram.

Nou, DDR4 RAM is gemiddeld 60GB/s read, en 50GB/s write, met zo'n 65ns latency.
Een M.2 disk kan theoretisch maximal 4GB/s, en momenteel zijn de vlotste schijven rond de 2.5GB/s .

Begrijp me niet verkeerd, dat is al veel sneller dan de 250MB/s van je mechanische HDD, maar nog lang niet zo snel als je intern geheugen.
Alle videokaarten die RAM geheugen delen met het video geheugen (lees, de videokaart gebruikt RAM geheugen ipv dedicated geheugen) zijn (waren) niet vooruit te branden, laat staat dat de PC dat geheugen dan ook nog even uit de diskcache moet halen. Alles is relatief... snel is soms niet snel genoeg...

Nou, DDR4 RAM is gemiddeld 60GB/s read, en 50GB/s write, met zo'n 65ns latency.
Een M.2 disk kan theoretisch maximal 4GB/s, en momenteel zijn de vlotste schijven rond de 2.5GB/s .

Begrijp me niet verkeerd, dat is al veel sneller dan de 250MB/s van je mechanische HDD, maar nog lang niet zo snel als je intern geheugen.
Alle videokaarten die RAM geheugen delen met het video geheugen (lees, de videokaart gebruikt RAM geheugen ipv dedicated geheugen) zijn (waren) niet vooruit te branden, laat staat dat de PC dat geheugen dan ook nog even uit de diskcache moet halen. Alles is relatief... snel is soms niet snel genoeg...

Ik ben bekend met de snelheden, L3/l2/1 cache is nog sneller . Echter dat is niet wat ik met kwantificeren bedoelde. Noem eens een applicatie waar je merkbaar vertraging oploopt bij gebruik van bijvoorbeeld 4 gb ram ipv 8gb. Waar merk jij dat 'vlotter reageren' waar je het eerst over had?

Op een gemiddelde pc valt dat inderdaad wel mee. Videobewerking, of photoshoppen heeft echt wel baat bij meer geheugen.. Als je Hyper-V gebruikt om omgevingen te testen, dan helpt het natuurlijk ook wel.
In office of alledaagse applciaties merk je het natuurlijk niet, of minder..

Aangezien 32bit in Windows je maar 3.5GB RAM laat gebruiken is het ook niet zo vreemd dat ze er mee stoppen. Iedereen die een beetje wil gamen zit toch wel op 64bit tegenwoordig. Zonde om hier nog tijd in te steken.

Dan heeft je videokaart mogelijk al snel meer geheugen dan je pc . Als we als aanname nemen dat nieuwe videokaartdrivers met name optimalisaties hebben voor nieuwe games.

Wat hij bedoelt is dat het gros van de moderne games tegenwoordig een 64 bit OS vereist omdat de games meer dan 2GB RAM vereisen per proces. Het heeft dus geen zin meer om elke maand een 32 bit driver uit te brengen met de laatste optimalisaties, omdat er nauwelijks meer games zijn die optimalisaties nodig hebben en die op een 32 bit OS draaien.

Geldt de vuistregel nog dat je ram minstens 2x het formaat van je video geheugen moet hebbe

heeft die ooit gegolden dan? Ik heb er nog nooit van gehoord, Dus in hoeverre was het een vuistregel of een verkooppraatje...?

Stond vroege altijd op achterop de verpakking van een videokaart anno 2003 ofzo

Ben je niet in de war met een pagefile of swap partitie?

Heb hier 11GB VRAM met 16GB RAM. Als mijn RAM 8GB was geweest kon ik nog alles prima spelen. Dus nee, die regel geldt niet

Misschien een rare vraag maar is het wel mogelijk voor een 32-bit windows om meer dan 3,5GB ram van de videokaart te gebruiken? of regelen de drivers van de videokaart dat zelf?

goed dat ze dit doen, 32bit OS zou niet meer gebruikt moeten worden in deze tijd

32bit OS zou niet meer gebruikt moeten worden in deze tijd

Waarom niet, niks mis met 8/16/32-bit's operating systems...
Juist met de opkomst van IoT, waarbij we beperkte mogelijkheden in een zo klein mogelijke verpakking willen steken komen maken juist 8-bits systemen weer een opmars.

Noem eens een IoT apparaat met een AMD GPU die baat heeft bij maandelijkse driver optimalisaties voor videogames?...
Er werd uiteraard x86 32 bit bedoelt, een 32 bit Raspberry Pi oid is niet de doelgroep van dit artikel over AMD GPU's

Nou ja als er geen vraag was dan zou AMD al lang gestopt zijn met 32 bit drivers.

Vergeet ook niet dat in de nieuwste drivers ook budget en wat oudere GPU's worden ondersteund.
De code van 32 bit Windows zal denk ik gewoon gecopied/paste zijn van de 64 bit versie ipv dat AMD moet uitzoeken voor welke GPU's het zin heeft om 32 bit windows te maken.

[Reactie gewijzigd door rickboy333 op 25 oktober 2018 23:57]

AMD is dan ook gestopt? Daar gaat het hele artikel over
Dat het niet 10 jaar geleden is gedaan zal zijn omdat er toen wel nog vraag naar was, dat het niet vorig jaar gedaan is, tja...
Copy/pasten is leuk, maar juist de optimalisaties zullen niet altijd even makkelijk zo werken.

Voor ARM 32 bit heb je LPAE.

iOs is tegenwoordig exclusief 64-bit
De volgende MacOS ontdoet zich van 32-bit
AMD stopt ondersteuning voor 32-bit

Windows zal nog wel een tijdje duren maar ik kan me zomaar voorstellen dat 32-bit uit de mobiele platformen gaat.

Windows Server is al vanaf 2008 R2 64 bit only dus de beginstappen zijn al ruim 11 jaar geleden gedaan.

Overigens geldt dat alleen voor het server OS. Windows 10 is 'gewoon' in 32 bits variant beschikbaar...

'Windows Server is al vanaf...'
Windows Server 10 zou wat zijn

Maar 64 bit only betekent alleen dat het OS zelf niet meer in een 32bits versie uitgebracht is, niet dat het alleen maar 64bit applicaties ondersteund. Dat is bij iOS en (mogelijk) de volgende versie van MacOS dus niet, daarbij is dat oude 32 bits applicaties gewoonweg niet meer werken.

Jammer, nu kan mijn Snapdragon 850 niet met een Vega64 werken

microsoft werkt ook an 64bit windows applicaties on arm momenteel tho

Mag wel eens tijd worden dat het legacy spul niet meer ondersteund gaat worden

Enige wat tegenwoordig nog op 32 bit draaien zijn sommige supergoedkope Windows tablets. Die hebben veelal maar 1 of 2gb ram. Maar daar zitten eigenlijk altijd Intel Graphics in, dus ik neem aan dat daar wel drivers voor worden gemaakt.

Tjah... We hebben onderhand al bijna 15 jaar 64-bit processors. Zal tijd worden ;P

Ik geef ze geen ongelijk, bij mijn Vega 64 stond op de doos dat het vereist is om een 64-bit besturingssysteem te draaien voor support. Gezien de kaarten die ze uitbrengen meer ram hebben dan 32-bit ondersteunen is dit een logische stap om kostbare resources over te houden. Eerder hebben ze een vergelijkbare stap gemaakt door geen driver meer te ontwikkelen die specifiek voor Windows 8 is gemaakt (Heb zelf de Windows 7 driver daar getest en dat werkt prima). Mensen met 32-bit zullen de nieuwe features en optimalisaties in de drivers waarschijnlijk niet nodig hebben en kunnen gebruik maken van deze driver tot zij upgraden naar een nieuwer systeem.

Wat mij betreft mogen we x86 compleet stoppen, de emulatie en de programmas zelf dus ook. zorgt voor een stuk minder rotzooi.

Backwards compatibility is het heilige antwoord hier. Omdat 32 bit Windows programma's ondersteund uit de 16 bit era is 32 windows 10 een oplossing voor veel bedrijven die nog met oudere software werkt. Want zolang het veilig is en het werkt gewoon, waarom vervangen? En je zult verstelt staan hoeveel bedrijven nog legacy software gebruiken (anders zou Microsoft 32 bit windows ook niet aanbieden, er is dus wel degelijk vraag naar) nog maar te zwijgen van de embedded markt.

Ook zie ik veel 32 bit Windows op stick computers. Ik weet verder niet of daar nog een specifieke reden voor is.

Nog veel ouder.. Ik ken 32-bits applicaties(met updates en patches om eruit te laten zien) die mijn 64-bits werkstation flink op zijn donder geven. Als ik een 20 jaar oude game wil spelen, of het nodig vind om een 30 jaar oude applicatie te starten, wil ik de vrijheid om dat te doen.

Windows 10 zou al 64-bits only zijn, maar de markt vraagt om dingen die alleen werken onder een 32-bits omgeving.. ik zal een Nederlands bedrijf met een enorm gebouw die SQL-niveau 2005, en 32 bits OS-en als enige hadden te bieden omdat ze te stom waren om hun software niet door te ontwikkelen(met name actief in de zorg), maar als voorbeeld aangeven. Heeft ze bijna de kop gekost, gelukkig, maar die stap zou niet nodig zijn. De partij waar ik toen zat kon hun servers niet upgraden naar windows 2012 omdat ze geen 64-bits deden, anno 2013... Bij een andere partij had ik eind 2014 met software voor een (nieuw) industrieel meetapparaat.dat niet hoger dan in XP kon draaien.

Maar AMD heeft (veel) legacy support, maar begrijpelijk dat ze voor deze specifieke tak de support laten vallen. In de markt van thuiscomputers en gamers heeft niemand een PC gekocht die geen 64-bits ondersteuning bied in de afgelopen 6 jaar.. Degene die dat wel doen kunnen gewoon doordraaien op oudere drivers, want zo nauw zal de support voor hun behoeftes niet hangen.

Ook zie ik veel 32 bit Windows op stick computers. Ik weet verder niet of daar nog een specifieke reden voor is.

Daar is wel degelijk overna gedacht en een goede reden voor.
Zo'n stick-pc heeft meestal maar 1 à 2GB ram geheugen met een niet bepaald snelle processor.
64 bits voegt gewoon helemaal niks toe behalve dat het meer ram geheugen kost en het systeem trager maakt / trager opstart.
Een 64 bits OS / programma is heel mooi en kan veel voordelen bieden, maar wat men dus soms vergeet is om deze voordelen te verkrijgen je niet enkel moet inleveren op compatibiliteit ( 16 bit apps en wat hardnekkige 32 bit apps ) maar dus ook performance.
Moderne, snellere en bij voorkeur pc's met meer dan 4GB aan ram profiteren wel echt van 64 bits en zullen dan netto meestal ook beter presteren dan dat deze machines 32 bits zouden draaien.

Mwa, daar ben ik het niet helemaal mee eens. De kracht van het x86 platform is altijd juist de terugwaartse compatibiliteit met bestaande software geweest. Dit is ook de reden dat we nu allemaal x86-64 gebruiken en geen IA-64.

Da's moeilijk met zekerheid te zeggen. IA-64 zat op de Itanium processors. Die waren erg duur en ook nodeloos lastig in gebruik (voor de compiler). Wat ik wil zeggen is dat IA-64 nog heel veel nadelen had buiten het feit dat de x86 emulatie niet om over naar huis te schrijven was.

Maar je hebt natuurlijk wel gelijk als je zegt dat compatibiliteit een grote kracht is van x86. Soms is het ook een groot nadeel overigens; iedereen is er ondertussen aan gewend geraakt om Windows programma's te downloaden, wat niet de veiligste methode is om aan applicaties te komen.

Fietelijk zeg je dus dat bijv. alle wat oudere games niet meer hoeven te werken om maar van x86 af te zijn?

Welk voordeel voor de eindgebruiker zie je daar in?

Als echt alle software en games die vanaf nu uitkomen in een x64 smaak komen zou je jou idee over een jaar of 10 eens realistisch kunnen overwegen.

[Reactie gewijzigd door !mark op 25 oktober 2018 22:25]

Oudere games kan ik per definitie niet meer draaien, of er nou wel of niet een 32bit OS* op zit. Boel is al dusdanig stokoud dat het echt niet meer draait.

x86 Heeft zijn tijd gewoon gehad, hoogste tijd dat men volledig overstapt naar x64


*Met een modern OS, voordat er weer een wijsneus komt met win98 of iets dergelijks....

Wat mij betreft mogen we x86 compleet stoppen,

Sorry, maar x86 zegt helemaal niets over of een CPU 32-bits of 64-bits is. x86 is de overkoepelende instructieset architectuur van Intel. Een 64-bits CPU kan net zo goed een x86 CPU zijn als een 32-bits CPU dat kan zijn. De 64-bits CPU gebruikt dan echter de x86-64 versie van de x86 instructieset.

Oorspronkelijk waren x86 CPU's 16-bit, daarna 32-bit, en sinds meer dan een decennium zijn de meeste x86 CPU's 64-bit, (of meer met SSE of AVX registers). Recente systemen met een 32-bits (of 16-bits) x86 CPU vind je tegenwoordig eigenlijk alleen nog maar in low powered of embedded systemen.

Backwards compatibility is juist de kracht (of zwakte) van x86. Heel veel applicaties die je op je PC kan (en zal) draaien zijn niet gecompileerd voor 64-bit maar voor 32-bits. Omdat x86 ook nog 32-bits ondersteunt kun je die in principe zonder emulatie draaien.

[Reactie gewijzigd door houseparty op 26 oktober 2018 11:17]

Windows is architectuur onafhankelijk. Er is een klein binary blobje in de NT kernel wat de vertaling naar de architectuur doet en dus met de CPU praat. Ik weet niet waar je ARM rotzooi terug vind in je x86/64bit windows, maar ik ben benieuwd of je dat terug kan vinden.

En voor de 32bit rotzooi @t link … Zolang bedrijven zoals Valve hun Steam applicatie nog als 32bit uitbrengen, gaan we er nooit vanaf komen.

Nee klopt daarom moet het er gewoon klaar mee zijn. backwards compatability is leuk maar voor oude games kan je het prima emuleren in scummvm bijvoorbeeld. zolang het blijft bestaan zullen mensen ervoor blijven ontwikkelen wat gewoon een probleem is. fasseer het nou gewoon uit na 15 jaar.

ScummVM werkt alleen voor bepaalde games (voornamelijk adventure games, toevallig wel net het genre dat ik graag speel, maar ook ScummVM ondersteund niet de 3d based games).
En jij vergeet dus dat een hoop mensen nog oudere applicaties hebben die perfect werken en waarvoor gewoon geen nieuwere versie zijn. Dat JIJ geen oudere applicaties hebt is een ander verhaal, maar bij heel veel bedrijven draaien nog meer dan genoeg oudere applicaties..

Ik noem ScummVM ook alleen maar als voorbeeld. Er is markt voor zoals je zelf ook al zegt, maar je hele processor met backwards compatability ontwerpen puur omdat er legacy software rondhangt is echt geldverspilling. laat die bedrijven het lekker zelf uitzoeken, hetzelfde met uefi legacy support. het zorgt voor zo veel meer gezeik en complexiteit voor misschien 0.1% van de gebruikers.

Zolang er nog een hoop 'legacy' applicaties zijn die veel gebruikt worden zal het ook nog lang duren voordat 32bit vervangen wordt. Maar aan de andere kant, who cares? in heel veel applicaties heeft 64bit totaal geen toegevoegde waarde.. Zolang de applicatie maar werkt zal het mij een rotzorg zijn of die nu in 32 bit of 64 bit draait.

Een programma wordt niet beter van gecompileerd worden als 64bit . Lees voor een goed voorbeeld hiervan bijvoorbeeld dit artikel:
https://www.infoq.com/news/2016/01/VS-64-bit

Your pointers will get bigger; your alignment boundaries get bigger; your data is less dense; equivalent code is bigger. You will fit less useful information into one cache line, code and data, and you will therefore take more cache misses. Everything, but everything, will suffer. Your processor's cache did not get bigger. Even other programs on your system that have nothing to do with the code you’re running will suffer. And you didn’t need the extra memory anyway. So you got nothing. Yay for speed-brakes.

.

Het enige voordeel van als 64 bit compilen is dat je meer geheugen kunt aanspreken (Steam blijft makkelijk binnen de 2GB) en enkele nieuwe instructies kunt aanspreken (handig als je wil number crunchen, nutteloos als je gewoon een storefront wil tonen).

Het als 64bit compilen lost ook weinig op, we zitten nog steeds op de x86-64 instructieset. Geen enkel 64bit programma zou kunnen draaien als we alle x86 instructies er uit gooien. Omdat de '64' in dit geval slechts een kleine extensie is van de x86 instructieset.

heb je een clue van hoe veel ARM word gebruikt?

het was meer een sarcastische opmerking tegenover zijn domme opmerking om maar met x86 te stoppen.. Heb je een clue van hoe veel x86 gebruikt wordt?

Ik gebruik al jaren geen ATI/AMD kaart meer sinds ik mijn NVIDIA GTX480 en latere kaarten ging gebruiken. De (toen nog) ATI kaarten die ik nog heb (Radeon 1650 en 1950), worden al jaren niet meer door de drivers ondersteunt dus veranderd en voor mij weinig, maar ik kan mij voorstellen dat er genoeg mensen die een oude computer hebben draaien voor de kids die niet alles meer kan of gaat spelen . . .

Als je een 32 bit pc hebt zal je daar niet de duurste AMD GPU in hebben, of zelfs maar iets van meer dan 50,- en zullen GPU driver optimalisaties nauwelijks nut hebben aangezien je per process (game) gewoon beperkt bent op 2GB geheugen, er is geen markt voor om daar nog de kosten aan ontwikkeling in te steken met nieuwe drivers nu x64 al zo'n 15 jaar op de markt zijn.

Nou ja, het gaat alleen om updates he? Ze hebben de driver niet teruggetrokken ofzo.

Dat vroeg ik mij nou af, Is er straks een driver die alléén x64 is? Dus waar helemaal geen x86 meer in terug te vinden is? Zou erg welkom zijn hierzo! scheelt weer ruimte en die meuk heb ik toch niet nodig.