AMD presenterar Radeon R9 285 "Tonga Pro"

känns ju puckat att bara montera 2GB RAM på ett nytt kort, så jag skulle inte köpa det..

Vilket ju har med storleken på minnesbussen att göra, så så vidare puckat är det ändå inte om man känner till dess begränsningar.

Kommer fx-83XX sänkas i pris?

Det är dock nVidia som har Maxwell medan 285/280X är AMDs grafikkort.

En snabb koll visar också att mer minne än två inte är så användbart eftersom bussen inte klarar att leverera tillräckligt med FPS, vi snackar någonstans runt 2.5GB minne. Så fyra GigaByte är inte kostnadseffektivt i detta sammanhang, tyvärr.

Så gör Nvidia på Titan/Titan Black också, dvs, att man delar 32-bitar bussbredd per 2 minneschip. Inte optimalt, men får man bara upp hastigheten tillräckligt så är det säkert försumbar förlust. Det är med största sannolikhet så Nvidia även kommer göra med 870/880 om de nu bygger på samma krets. Jag antar att AMD's approach är något bättre där (512-bitars buss), där alla minnen får sina egna kanaler till minneskontrollern. Men det finns garanterat andra nackdelar där, om inte annat så blir ju de chippen tokvarma

Hur tänker du där? Visst det kan säkert bli en viss fps-skillnad, men det är ju inte så att GPU'n inte klarar fylla minnet. Det mesta bör ha med minneshastigheten/kontrollern att göra. På 680-korten (med 4GB) lär minnesbussen ex. flaska mer än på ett 770 där det är hela 1Ghz högre minnesbuss som standard.

och varför göra bussen mindre än föregångaren? fortfarande puckat å kalla den 285,

Tonga kan bli riktigt intressant när de drar upp minnesbandbredden med tanke på att den är så pass låg nu och kortet ändå presterar så bra.

Låt detta vara den sista 28nm-kretsen som ser dagens ljus. Jag har sandpapper hemma som har finare struktur än den här stenålderstekniken.

Det är just det som är min poäng. Rimligtvis borde det bara 270 -> 270X -> 280 -> 280X -> 285 -> 285X -> Osv.

Det är ju just det den är för ju mer kortet ska pumpa ut i Frames Per Second desto mer bandbredd behöver du för att kunna saturera GPU, därav minnesbussens tillkortakommanden. Som jag just skrev och också andra har skrivit även här på SC så är fyra GB inte optimalt just p.g.a detta.

Så ja, du svarar att det inte är sant sedan vänder du på det och påstår det jag sa, nice!

Ska vi börja gissa specs?
Jag gissar 280mm² och en fjärdedel så hög FP64-prestanda som Tahiti. Utöver de redan kända färre minneskontrollerna så gissar jag att de är effektivare, tar mindre plats och drar mindre ström stycket.

Exakt hur ser din matte ut när du kommer fram till detta?

Nej, inte det minsta. Behöver inte tramsa här. Han säger att minne kan användas till mer än bara att producera nästa frame, men poängterar att OM minnet bara skulle användas till att producera nästa frame så skulle bussen klara av att skicka 2,7GB per frame.

Men om du sitter och skickar 2GB per frame och något nytt ska in i bild med nya texturer. Vad händer då? Har du en FPS-drop i väntan på RAM? Eller har du 4GB minne så att du kan fortsätta rendera i samma takt?

Forfarande är det så att du inte kan få in mer data genom bussen än ~2.7GB om du ska har hög FPS i krävande spel. Vad är det som är så svårt att förstå?

Edit: En liten förklaring http://linustechtips.com/main/topic/44197-memory-bus-size-and...

Ja men stirra dig blind på den siffran då. Spela dum du, inte riktigt schysst beteende i en diskussion i mina ögon.

Angående den där liknelsen, den suger. Man kan inte låtsas att det är data som data som det är med vatten, varje frame kan behöva en unik uppsättning data. Då måste man kunna förse GPUn med det, inte bara skicka samma 2GB om och om igen.
Du kan ju vara intellektuellt ohederlig och låtsas som att du inte läst vår förklaring. För lite schysst stämning i forumet så kan man ju åtminstone bemöta någons argument. Men du låtsas att du inte sett våra argument för varför din förklaring inte håller, du bemödar dig inte med att bemöta dem utan du upprepar dig bara.
Du envisas med att minnets absolut enda uppgift är att förse GPUn med det den behöver för att räkna ut nästa frame. Du låtsas att du inte läst att minnet även behöver kunna ha annan data ifall nästnästa frame kräver det, eller framen efter det.

Normalt är nog ändå att en GPU behöver en hel del mindre minne än 2GB för att räkna på en frame, det den behöver större minne till främst är som buffert för att snabbt kunna rendera helt andra frames ifall något nytt plötsligt kommer i bild.

Du är mycket motsägelsefull nu då du först skriver att jag inte har rätt och sedan skriver att GPU kanske behöver ny uppsättning av data och var kommer de isf ifrån; från luften? Jo med största sanning just genom den där bussen, som ju fortfarande bara är si och så bred beroende på kort, i detta fall 256 bitar och det enda som kan ändra på detta för hållande är om minnesklockan höjs så att mer data kan "flowa" genom den. Dina argument biter inte på mig då du nog inte riktigt har satt dig in i hela förloppet, iaf som det verkar, men jag gillar att diskutera och få fram lösningar så hoppas jag inte stör dig allt för mycket.

Ditt resonemang haltar då du ju inte på något magiskt sätt kan fylla de resterande två GB minne med nytt material/data då ju bussen fortfarande är på gränsen för vad den kan hantera. Så med fyra GB och trång buss fungerar det fortfarande inte att fylla fyra GB fullt ut.

Alltså menar du allvar? Du spelar inte bara dum nu? Menar du att du inte kan adressera 4GB data med en 256bit buss? Bussbredden har inget som helst att göra med hur mycket minne du kan ha i en minneskrets. Du kan fylla 4GB med hur snäv buss som helst. Det enda bussen begränsar är hur snabbt du kan läsa och skriva minnet, och detta då i kombination med frekvens.
Nu får du skärpa till dig lite, bemöt allt jag skriver och bemöt inte bara en liten del med någon irrelevant halmdocka. Förklara hur dataadressering påverkas av bussbredd. Förklara hur jag kan ha 8GB minne på en 64-bitars kanal i min dator om 256bit buss bara kan adressera 2GB. Antingen det eller så får du medge att man kan ha 4GB data i ett minne som ansluts via 256bit buss.

Om du nu medger att man kan ha 4 GB lagrat i minnet, så måste du medge att ett 4GB minne kan hantera att skicka 2GB texturer i en frame, och skicka 2GB av helt andra texturer nästa frame. Medan ett 2GB minne bara klarar av att mata den första framen, det måste laddas med data från RAM för att kunna mata GPU inför nästa frame.

Så, berätta nu vad det brister för dig. Och utveckla.

Alltså adresseringen har inget med detta att göra utan det att den inte hinner ladda upp detta eftersom bussen inte klarar mer, den är redan saturerad för den höga FPS du anser dig behöva. Snälla blanda inte in självklarheter.

Ditt påstående kräver ett flertal felaktiga antaganden för att gå ihop.

Felaktigt antagande 1:
Spelet laddar inte in texturer i förväg.
Hur det fungerar:
Spelet laddar i så hög utsträckning som minnesmängden tillåter och efter behov in texturer i förväg, oftast vid start av spelet, banan eller vid miljöbyte.

Felaktigt antagande 2:
Bussen är precis jämnt belastad hela tiden.
Hur det fungerar:
Bandbredden som behövs går upp och ner hela tiden. Om du behöver 2GB/frame bandbredd vid vissa tillfällen så behöver du mycket mindre vid andra. Där kan spelet passa på att prefetcha texturer för att se till att minnet är fyllt med aktuella texturer.

Felaktigt antagande 3:
Om det måste laddas data från RAM så kommer det inte tilldelas bandbredd ifall bandbredden används för rendering.
Hur det fungerar:
Om spelet mot förmodan inte fyllt grafikminnet med texturer redan och det behöver en textur för att rendera nästa bild så kommer nästa bild få vänta tills texturen laddats från RAM.

Felaktigt antagande 4:
Textur laddat från RAM försvinner ur grafikminnet så fort det inte används, även om kapacitet finns.
Hur det fungerar:
Om du en gång laddat en textur till grafikminnet så kommer den finnas där nästa gång den behövs. Om inte spelet behövt mer än 4GB och texturen fått ge plats för annat. Men då är 4GB extra viktigt.

Eftersom dessa felaktiga antaganden inte stämmer så jo, även om minnesbussen är fullt upptagen så kan du visst ha 4GB texturer i minnet redo att ingå i de 2,7GB som kan skickas till GPU varje frame.

RAM = Random Access Memory, du behöver inte skyffla igenom minnet med början på noll för att komma åt texturerna som ligger uppe vid 4GB-gränsen. Du läser direkt den information du behöver, oavsett var den ligger.

Det är bäst om grafikminnet kan hålla alla texturer i minnet så att de finns tillgängliga redan innan de behövs. Måste du swappa texturer on-the-fly får du fps-drops.
Tex har du 3GB texturer fördelat på 1GB utomhus stadsscener, 1GB inomhusscener och 1 GB utomhus naturscener, då måste du ha mer än 3GB (vilket blir 4GB) grafikminne för att slippa fps-drops vid scenbyte.

Jag minns Americas Army. Det är väl i det närmaste bortglömt idag. Det laddade inte in texturer förens de behövdes. Ena laget startade i källaren och det var alltid fps-drops första gången man ser dagsljus och utomhustexturerna laddades in. Risken att bli snipad var överhängande. För att undvika detta hade alla som vana att snabbt springa fram till ett fönster och få fps-dropsen innan fienden hunnit komma nära. Efter detta kunde man obehindrat springa ut och in i byggnaderna utan fps-drops.
Samtliga texturer rymdes alltså i grafikminnet, och om allt hade laddats med en gång så hade man inte behövt 'titta ut' för bra flyt senare i matchen. Jag förmodar att de med lite grafikminne fick fps-drops varje gång de växlade mellan inomhus och utomhusscen.