«G-Sync-knuseren» fra AMD blir gratis på alle skjermer

[War]

Det var de 60millioner dollarene på gsynk ut vinduet^^

[Nizzen]

 

Det er grunn nok til å rakke ned på mantel nå, fordi det er ikkje konge enda. Har 2x 290, og de blir ikkje brukt mye for å si det slik. DX fungerer bedre og har mindre bugs enn mantel for meg.

Intel prosessor?

 

 

Hvem er det som har AMD cpu nå

[War]

Amd realiserer sikkert drømmen når man er 14 og må pante flasker eller ikke vet bedre, men har man hardware verdt mer en eneboligen så finner man fort ut at det er devil in disguise

[efikkan]

MantelMantle fungerer bra den for folk med både amd prosessor, amd gpu og spill som implementerer det bra (battlefield 4 er kanskje ikke det beste eksempelet her)

 

Så ingen grunn til å rake ned på mantel ennå.

Siden du ikke vet hva Mantle faktisk er, så klipper jeg inn et tidligere sitat fra meg selv:

De fleste av dere vet ikke hva Mantle er og hva det prøver å adressere. Tradisjonelt har GPUer fungert veldig enkelt; du velger input-data(1), velger en operasjon som skal utføres på dataen(2) og du velger hvor eventuell output skal lagres og data frigjøres(3). (eksempel: du binder en mesh og en tekstur til et område i GPUens minne, tegner, og så frigjør bindingen) Dette gjøres gjennom en rekke API-kall. GPUens fordel har vært evnen til å parallelisere, men til mer manipulering som et spill trenger til flere API-kall blir det. Eks: hvis du har en stor mesh av et detaljert statisk terreng kan du gjøre det med ett enkelt sett med kall, men om du vil animere et stort antall objekter så ender du opp med å sende API-kall for hvert av disse. Om du vil animere deler av et objekt blir det ennå mer komplisert osv. Hver gang vi sender slike kall til en GPU blir det ekstra overhead, og det hindrer optimal utnytting av GPUens prosesseringskraft. For å tillate mer mangfoldig og effektiv manipulasjon av data har GPUer siden OpenGL 1.5 og Direct3D 8 tillatt programmering av operasjonene som ser inne i GPUen. Dagens versjoner av OpenGL og Direct3D fungerer fremdeles veldig tungvindt, og opererer fremdeles på låste minneområder for inn- og utdata, og krever fremdeles store mengder API-kall i spill med mye dynamikk. OpenCL fungerer prinsippielt veldig likt med OpenGL på (1)(2)(3), som gjør at det er veldig utfordrende å utnytte effektivt. Programmering med disse APIene er også svært ulikt måten CPUer programmeres på.

 

Nå må jeg ta et lite sidespor; disse problemene er nettopp noe Nvidia har forsøkt å løse med CUDA. I CUDA er GPUen i langt større grad programmerbar til generelle operasjoner, er i stand til å aksessere vilkårlig data innen minneområde, avansert kontrollflyt, strømme data direkte fra PCIe-enheter og til og med kontrollere threads på GPUen. Å programmere i CUDA blir prinsippielt veldig likt med å programmere i C, som gjør det enklere å bruke CPU og GPU mest mulig effektivt sammen, fremfor OpenCL, OpenGL osv. hvor CPUen sløser mye ressurser på å styre GPUen. Nvidias GPUer er i stand til å styre minneallokering og threading internt, og andre APIer er for gamle til at de er designet for å utnytte dette. Parallelt med utviklingen av CUDA har Nvidia tilbydd utvidelser til OpenGL som utnytter samme egenskaper i GPUen til grafikk. Dette omtales ofte som "bindless graphics" og generell dataaksessering. Denne økte programmeringsfunksjonaliteten har blant annet to store fordeler:

1) Redusert overhead med mindre API-kall fra CPU

2) Mer effektiv utnyttelse av dyrebar L2-cache i GPUen, og kan gi raskere minneaksesser når GPUen selv får styre dette.

Selv tilbake på GT200-serien kunne dette gi omtrent 7.5x høyere VBO-ytelse, som er viktig til flere objekter som manipuleres. Dette har gradvis blitt utvidet til at GPUen nå kan aksessere f.eks. teksturdata direkte via pekere.

 

Den som forstår det jeg snakker om her forstår også at Mantle som enkelt og greit prøver å redusere overhead per API-kall bare er en mellomløsning. Alle GPU-programmerere vet at fremtiden ligger i å programmere GPUen direkte, så Mantle vil fungere som et botemiddel frem til at AMD har en GPU-arkitektur med mer funksjonalitet. Hverken AMD eller Intel er i nærheten av å kunne tilby den funksjonaliteten Nvidia har i GPUene sine, og derfor blir ikke OpenGL oppdatert til å utnytte dette på en stund. Det er muligheter for at AMD har muligheten for noe slikt med sin neste arkitektur som skal avløse GCN. Mantle er ikke en god løsning på noen av problemene, og burde heller kommet for 10 år siden.

 

Dessverre er det slik at utviklingen holdes tilbake av en rekke GPU-produsenter, deriblant også de små. Jeg ønsker at AMD og Nvidia tar seg sammen for å utforme en helt ny generasjon spesifikasjon ("OpenGL 5.0"), som følger mange av prinsippene Nvidia har brukt i CUDA, men selvsagt på en produsentnøytral måte. Jeg ønsker en spesifikasjon som er designet for å utnytte fremtidige GPUer optimalt, ikke for GPUer midt på 90-tallet. Det er noen som syter over at OpenGL burde hatt Direct3Ds objektmodell, men den har faktisk mer overhead og er også uansett utdatert.

Det blir uansett feil å fremstille det som at det er AMD-CPUer som utnytter Mantle godt, det er tvert imot at Mantle som klarer å motvirke AMDs ulemper. Endret 21. oktober 2014 av efikkan

[Domaldel]

 

 

 

Det er grunn nok til å rakke ned på mantel nå, fordi det er ikkje konge enda. Har 2x 290, og de blir ikkje brukt mye for å si det slik. DX fungerer bedre og har mindre bugs enn mantel for meg.

Intel prosessor?

Hvem er det som har AMD cpu nå

Flere en du tror.

Hva som er raskest og/eller mest hensiktsmessig kommer nemlig an på arbeids oppgaven prosessorene blir gitt.

En fx 8350 kan være raskere enn en i7 4750k eller tregere enn selv en (overklokket jubileums) pentium avhengig av oppgaven den blir gitt.

 

Om jeg skal spille dwarf fortess så er selvsagt en intel prosessor best pga en langt bedre enkeltråds ytelse (spillet benytter bare en enkel tråd og selv en pentium kan derfor potensielt yte bedre enn prosessorer med flere kjerner som f. eks. en i7 om du er heldig med overklokkingen)

 

I spill yter som regel intel bedre pga høyere enkeltråds ytelse og fordi få spill virkelig bruker mange tråder, og selv de som gjør det fyller ikke opp de gamle (noe som skal til for at fx serien skal skinne)

Men selv har jeg et bruks mønster som gjør at fx for meg personlig er et bedre alternativ en i5 (som fx 8350 konkurerer med på pris) eller en fire kjerners i7 (som er bedre så lenge kun seks eller ferre tråder er fylt opp)

En seks eller åtte kjerners intel prosessor ville nok vært enda bedre men med prisen på de prossessorene samt hovedkort og minne moduler som kan brukes med dem så kan det være det samme.

Da tar jeg heller noen få færre bilder pr sekund i gjennomsnitt på noen spill samt litt dårligere minimums hastighet.

Jeg ville uansett fått lavere hastighet selv med en fire kjernes intel prosessor pga andre ting jeg gjør.

(Hypertrådene kan bare virke på bekostning av de vanlige trådene så en intel kjerne med begge trådene fulle har dårligere ytelse på den enkelte tråden enn en amd modul (to forskjellige kjerner med vær sin tråd med noen få delte resurser) om de blir gitt flere oppgaver med reelle tall enn flyttall.

[Nizzen]

Det finnes desverre ingen grunn for å kjøpe AMD cpu nå. Det er min mening. Hadde det fantes en grunn, så hadde jeg hatt en

 

Fant ingen grunn her heller:

 

http://www.bit-tech.net/hardware/2013/06/12/intel-core-i5-4670k-haswell-cpu-review/4

Endret 21. oktober 2014 av Nizzen

[efikkan]

Hva som er raskest og/eller mest hensiktsmessig kommer nemlig an på arbeids oppgaven prosessorene blir gitt.

En fx 8350 kan være raskere enn en i7 4750k eller tregere enn selv en (overklokket jubileums) pentium avhengig av oppgaven den blir gitt.

Forklar et bruksscenario hvor en FX-8350 er bedre enn en i7-4670K. Nå snakker jeg om reelle bruksscenarier, ikke bare sære enkeltbenchmarks.

 

I spill yter som regel intel bedre pga høyere enkeltråds ytelse og fordi få spill virkelig bruker mange tråder, og selv de som gjør det fyller ikke opp de gamle (noe som skal til for at fx serien skal skinne)

Det er en gammel skrøne. Hverken Direct3D eller OpenGL støtter i dag bruk av flere CPU-kjerner samtidig, og det ville heller ikke gitt store gevinster. Flere kjerner hjelper kun til å hindre at kjernen med GPU context blir forstyrret, har du nok kjerner til at denne får fred så vil ikke flere kjerner hjelpe utover det.

 

Men selv har jeg et bruksmønster som gjør at fx for meg personlig er et bedre alternativ en i5 (som fx 8350 konkurerer med på pris) eller en fire kjerners i7 (som er bedre så lenge kun seks eller ferre tråder er fylt opp)

En seks eller åtte kjerners intel prosessor ville nok vært enda bedre men med prisen på de prossessorene samt hovedkort og minne moduler som kan brukes med dem så kan det være det samme.

Da tar jeg heller noen få færre bilder pr sekund i gjennomsnitt på noen spill samt litt dårligere minimums hastighet.

Jeg ville uansett fått lavere hastighet selv med en fire kjernes intel prosessor pga andre ting jeg gjør.

(Hypertrådene kan bare virke på bekostning av de vanlige trådene så en intel kjerne med begge trådene fulle har dårligere ytelse på den enkelte tråden enn en amd modul (to forskjellige kjerner med vær sin tråd med noen få delte resurser) om de blir gitt flere oppgaver med reelle tall enn flyttall.

HT er ikke egne kjerner, det er "virtuelle kjerner" som utnytter dødtid på de eksisterende kjernene.

 

Å ha flere kjerner slik at spill får jobbe uforstyrret i forhold til bakgrunnsprosesser er riktig tenkt, men når en i5 har cirka dobbel ytelse per kjerne så har ikke AMDs 8 "kjerner" noe reelt fortrinn over Intel. Argumentet ditt hadde derimot vært gjeldende for en firekjerne mot en seks- eller åttekjerne fra Intel, hvor dette kan bidra til jevnere spillytelse.

[Domaldel]

 

MantelMantle fungerer bra den for folk med både amd prosessor, amd gpu og spill som implementerer det bra (battlefield 4 er kanskje ikke det beste eksempelet her)

 

Så ingen grunn til å rake ned på mantel ennå.

Siden du ikke vet hva Mantle faktisk er, så klipper jeg inn et tidligere sitat fra meg selv:

De fleste av dere vet ikke hva Mantle er og hva det prøver å adressere. Tradisjonelt har GPUer fungert veldig enkelt; du velger input-data(1), velger en operasjon som skal utføres på dataen(2) og du velger hvor eventuell output skal lagres og data frigjøres(3). (eksempel: du binder en mesh og en tekstur til et område i GPUens minne, tegner, og så frigjør bindingen) Dette gjøres gjennom en rekke API-kall. GPUens fordel har vært evnen til å parallelisere, men til mer manipulering som et spill trenger til flere API-kall blir det. Eks: hvis du har en stor mesh av et detaljert statisk terreng kan du gjøre det med ett enkelt sett med kall, men om du vil animere et stort antall objekter så ender du opp med å sende API-kall for hvert av disse. Om du vil animere deler av et objekt blir det ennå mer komplisert osv. Hver gang vi sender slike kall til en GPU blir det ekstra overhead, og det hindrer optimal utnytting av GPUens prosesseringskraft. For å tillate mer mangfoldig og effektiv manipulasjon av data har GPUer siden OpenGL 1.5 og Direct3D 8 tillatt programmering av operasjonene som ser inne i GPUen. Dagens versjoner av OpenGL og Direct3D fungerer fremdeles veldig tungvindt, og opererer fremdeles på låste minneområder for inn- og utdata, og krever fremdeles store mengder API-kall i spill med mye dynamikk. OpenCL fungerer prinsippielt veldig likt med OpenGL på (1)(2)(3), som gjør at det er veldig utfordrende å utnytte effektivt. Programmering med disse APIene er også svært ulikt måten CPUer programmeres på.

 

Nå må jeg ta et lite sidespor; disse problemene er nettopp noe Nvidia har forsøkt å løse med CUDA. I CUDA er GPUen i langt større grad programmerbar til generelle operasjoner, er i stand til å aksessere vilkårlig data innen minneområde, avansert kontrollflyt, strømme data direkte fra PCIe-enheter og til og med kontrollere threads på GPUen. Å programmere i CUDA blir prinsippielt veldig likt med å programmere i C, som gjør det enklere å bruke CPU og GPU mest mulig effektivt sammen, fremfor OpenCL, OpenGL osv. hvor CPUen sløser mye ressurser på å styre GPUen. Nvidias GPUer er i stand til å styre minneallokering og threading internt, og andre APIer er for gamle til at de er designet for å utnytte dette. Parallelt med utviklingen av CUDA har Nvidia tilbydd utvidelser til OpenGL som utnytter samme egenskaper i GPUen til grafikk. Dette omtales ofte som "bindless graphics" og generell dataaksessering. Denne økte programmeringsfunksjonaliteten har blant annet to store fordeler:

1) Redusert overhead med mindre API-kall fra CPU

2) Mer effektiv utnyttelse av dyrebar L2-cache i GPUen, og kan gi raskere minneaksesser når GPUen selv får styre dette.

Selv tilbake på GT200-serien kunne dette gi omtrent 7.5x høyere VBO-ytelse, som er viktig til flere objekter som manipuleres. Dette har gradvis blitt utvidet til at GPUen nå kan aksessere f.eks. teksturdata direkte via pekere.

 

Den som forstår det jeg snakker om her forstår også at Mantle som enkelt og greit prøver å redusere overhead per API-kall bare er en mellomløsning. Alle GPU-programmerere vet at fremtiden ligger i å programmere GPUen direkte, så Mantle vil fungere som et botemiddel frem til at AMD har en GPU-arkitektur med mer funksjonalitet. Hverken AMD eller Intel er i nærheten av å kunne tilby den funksjonaliteten Nvidia har i GPUene sine, og derfor blir ikke OpenGL oppdatert til å utnytte dette på en stund. Det er muligheter for at AMD har muligheten for noe slikt med sin neste arkitektur som skal avløse GCN. Mantle er ikke en god løsning på noen av problemene, og burde heller kommet for 10 år siden.

 

Dessverre er det slik at utviklingen holdes tilbake av en rekke GPU-produsenter, deriblant også de små. Jeg ønsker at AMD og Nvidia tar seg sammen for å utforme en helt ny generasjon spesifikasjon ("OpenGL 5.0"), som følger mange av prinsippene Nvidia har brukt i CUDA, men selvsagt på en produsentnøytral måte. Jeg ønsker en spesifikasjon som er designet for å utnytte fremtidige GPUer optimalt, ikke for GPUer midt på 90-tallet. Det er noen som syter over at OpenGL burde hatt Direct3Ds objektmodell, men den har faktisk mer overhead og er også uansett utdatert.

Det blir uansett feil å fremstille det som at det er AMD-CPUer som utnytter Mantle godt, det er tvert imot at Mantle som klarer å motvirke AMDs ulemper.

 

Like fullt så frigjøres resurser slik at prossessoren ender opp med å ta seg av det som virkelig må bli gjort av den istedenfor å bli belastet med alle disse unødvendige oppgavene som den ellers må gjøre og som gjør at grafikkkortets opdaterings hastighet blir mere bundet til enkeltråds hastigheten til prossessoren enn den ærlig talt trenger å være.

 

Hva grafikk kort med prosessering angår så ser jeg frem til å lese om hva som kommer til å skje med HSA.

Får de det til å fungere bra på en prosessor så ser jeg ingen grunn til at de ikke kan overføre det de lærer der til grafikkkortene.

 

Uansett ser jeg på Mantle som et steg i riktig retning siden den blir åpen til forskell fra CUDA.

Og uansett så er teknologien ny, så det kommer selvsagt til å ta tid før den blir relativt vanlig i spill. (Akkurat som physx blir den neppe universell med mindre Nvidia velger å støtte mantel med sine grafikk kort)

[efikkan]

Like fullt så frigjøres resurser slik at prossessoren ender opp med å ta seg av det som virkelig må bli gjort av den istedenfor å bli belastet med alle disse unødvendige oppgavene som den ellers må gjøre og som gjør at grafikkkortets opdaterings hastighet blir mere bundet til enkeltråds hastigheten til prossessoren enn den ærlig talt trenger å være.

Slik det er i dag så yter en firekjerners i5 bedre til spill enn en åtte-"kjernes" FX-CPU fra AMD, selv om mye kjører i bakgrunnen. At AMD har flere "kjerner" veier ikke opp nok for dårligere kjerner.

 

Uansett ser jeg på Mantle som et steg i riktig retning siden den blir åpen til forskell fra CUDA.

Og uansett så er teknologien ny, så det kommer selvsagt til å ta tid før den blir relativt vanlig i spill. (Akkurat som physx blir den neppe universell med mindre Nvidia velger å støtte mantel med sine grafikk kort)

CUDA-kompilatoren er åpen i dag i motsetning til Mantle, og er ikke noe luftslott.

[Domaldel]

 

Hva som er raskest og/eller mest hensiktsmessig kommer nemlig an på arbeids oppgaven prosessorene blir gitt.

En fx 8350 kan være raskere enn en i7 4750k eller tregere enn selv en (overklokket jubileums) pentium avhengig av oppgaven den blir gitt.

Forklar et bruksscenario hvor en FX-8350 er bedre enn en i7-4670K. Nå snakker jeg om reelle bruksscenarier, ikke bare sære enkeltbenchmarks.

 

I spill yter som regel intel bedre pga høyere enkeltråds ytelse og fordi få spill virkelig bruker mange tråder, og selv de som gjør det fyller ikke opp de gamle (noe som skal til for at fx serien skal skinne)

Det er en gammel skrøne. Hverken Direct3D eller OpenGL støtter i dag bruk av flere CPU-kjerner samtidig, og det ville heller ikke gitt store gevinster. Flere kjerner hjelper kun til å hindre at kjernen med GPU context blir forstyrret, har du nok kjerner til at denne får fred så vil ikke flere kjerner hjelpe utover det.

 

Men selv har jeg et bruksmønster som gjør at fx for meg personlig er et bedre alternativ en i5 (som fx 8350 konkurerer med på pris) eller en fire kjerners i7 (som er bedre så lenge kun seks eller ferre tråder er fylt opp)

En seks eller åtte kjerners intel prosessor ville nok vært enda bedre men med prisen på de prossessorene samt hovedkort og minne moduler som kan brukes med dem så kan det være det samme.

Da tar jeg heller noen få færre bilder pr sekund i gjennomsnitt på noen spill samt litt dårligere minimums hastighet.

Jeg ville uansett fått lavere hastighet selv med en fire kjernes intel prosessor pga andre ting jeg gjør.

(Hypertrådene kan bare virke på bekostning av de vanlige trådene så en intel kjerne med begge trådene fulle har dårligere ytelse på den enkelte tråden enn en amd modul (to forskjellige kjerner med vær sin tråd med noen få delte resurser) om de blir gitt flere oppgaver med reelle tall enn flyttall.

HT er ikke egne kjerner, det er "virtuelle kjerner" som utnytter dødtid på de eksisterende kjernene.

 

Å ha flere kjerner slik at spill får jobbe uforstyrret i forhold til bakgrunnsprosesser er riktig tenkt, men når en i5 har cirka dobbel ytelse per kjerne så har ikke AMDs 8 "kjerner" noe reelt fortrinn over Intel. Argumentet ditt hadde derimot vært gjeldende for en firekjerne mot en seks- eller åttekjerne fra Intel, hvor dette kan bidra til jevnere spillytelse.

Tja, de fleste "vanlige" tester har neppe særlig mange andre programmer enn selve testen kjørende i bakgrunnen. De fleste spillere som lager sin egen PC prøver jo å unngå bloatware som pesten. Men når det er mange prosesser (andre en de som har med OpenCL, OpenGL og directx å gjøre) så er det en fordel med flere tråder siden det gir flere forskjellige "køer" som oppgavene kan fordeles på uten at de kommer i veien for hverandre.

 

(Du ungår derfor den forstyrrelsen du nevnte, og ja jeg gjør nok samtidig til at de *vil* bli forstyrret)

Og siden det er snakk om forskjellige programmer så er det *ikke* snakk om at oppgavene i de programmene har informasjon som spillene trenger eller motsatt, så parallelisering er definitivt ikke et problem.

 

Forøvrig, jeg argumenter jo *for* amds prosessorer her...

Tror du virkelig at jeg tror at en modul er der samme som en kjerne eller at en intel kjerne med to tråder er det samme som en modul?

 

Jeg er fullt klar over at hypertråder dreier seg om at man simpelthen bytter catchen (hva nå det blir på norsk) mens en annen oppgave blir gjort og at det derfor ikke blir gjort to oppgaver på samme tid, og ja, det er lurt, du slipper å laste ut informasjon fra catchen til ram fra den første oppgaven og fra ram til catchen for den andre for å bytte mellom oppgaver slik du må med en vanlig kjerne.

Men fordi prosessoren kun kan *arbeide* med en oppgave (selv om den kan ha en annen oppgave på vent i catchen mens den venter på nødvendig informasjon eller på at den andre oppgaven blir ferdig) så vil de likevel forsinke hverandre litt.

Så ytelsen på den enkelte tråden sett utenfra på to tråder på en enkel intel prosessor vil vise en svært rask tråd mens den andre er tom men de to trådene vil likevel ikke yte like bra som to enkel kjerner fra amd i en amd modul når både intel kjernen og amd modulen har to fulle tråder.

Men nå snakker jeg om 4750 (uten en k) mot en fx 8350 (som alltid er ulåst for overklokking uten at det koster ekstra).

Tross alt så ble fx 8350 utviklet når i7 3750k var den beste prosessoren for den gjevne mannen i gata (seks kjernes prosessoren til intel var nå tross alt i en annen liga både på ytelse og pris)

Og fx 8350 var tol tider bedre enn den da, og selv nå greier den av og til å yte bedre enn 4750k på standard hastighet om du overklokker fx prosessoren.

Av og til slår den selv overklokkede 4750er, skjønt jeg er enig o at vi definitivt snakker om unntakene og ikke regelen.

Det er ikke verst for en såppas gammel prosessor.

Spesielt med tanke på prisen.

Du får kanskje mere ytelse i de fleste situasjoner med i7 prosessorene, men fx 8350 slår i5 ofte og i7 en sjeldent gang og ligger ikke lenger bak i andre tilfeller enn at fordelene overgår ulempene i mitt eget tilfelle.

Disse prossessorene er flinke på forskjellige ting.

 

Ps. En intel kjerne er ikke 1.5 x en amd kjerne men nermere 1.4, men det avhenger av om det dreier seg om reelle tall eller flyttall, og om det er enkel presisjon eller dobbel presisjon det dreier seg om.

 

Pps. Beklager bastante og raske uttalelser.

Hadde en hund som måtte på tur og er litt trett.

Men altså, så vidt jeg har forstått, har man en intel cpu og en amd cpu som begge kjører det remmer og tøy kan tåle så blir kjernene i intel cpuen omtrent tilsvarende 1, 4 amd kjerner, eller fire intel kjerner blir omtrent 5, 8 amd cpuer, (i noen sammenhenger, kommer selvsagt an på koden som kjøres, amd lcpuen iker reelle tall, intel er bedre på flyttall)

Men det forholdstallet forutsetter at alle tråder faktisk blir fylt (jeg snakker 100% her ikke 80%).

Har de mindre å gjøre så blir enkelt tråds ytelsen hos intel mere merkbar.

Så ja, som regel vil en i5 kjennes bedre ut enn en fx 8350 i spill selv med noen andre oppgaver.

Endret 21. oktober 2014 av Domaldel

[War]

Snevert på gevinnstene her.

Kommer på en ting hvor amd er helt konge, bussbruk mot cpu på folding.

1-2% VS nvidia som spiser 33% av en x16 eller 66% av en x8 og da flaskehalser på x4

Jalla driverkoding.

 

AMD-favør dog urelatert Må jo trekke fram det man kan

Endret 21. oktober 2014 av War

[DuraN]

I tillegg ville det vært bedre om man klarte å bruke riktig benevning på Intel-CPU'er

Endret 21. oktober 2014 av DuraN

[Domaldel]

 

Like fullt så frigjøres resurser slik at prossessoren ender opp med å ta seg av det som virkelig må bli gjort av den istedenfor å bli belastet med alle disse unødvendige oppgavene som den ellers må gjøre og som gjør at grafikkkortets opdaterings hastighet blir mere bundet til enkeltråds hastigheten til prossessoren enn den ærlig talt trenger å være.

Slik det er i dag så yter en firekjerners i5 bedre til spill enn en åtte-"kjernes" FX-CPU fra AMD, selv om mye kjører i bakgrunnen. At AMD har flere "kjerner" veier ikke opp nok for dårligere kjerner.

 

Uansett ser jeg på Mantle som et steg i riktig retning siden den blir åpen til forskell fra CUDA.

Og uansett så er teknologien ny, så det kommer selvsagt til å ta tid før den blir relativt vanlig i spill. (Akkurat som physx blir den neppe universell med mindre Nvidia velger å støtte mantel med sine grafikk kort)

CUDA-kompilatoren er åpen i dag i motsetning til Mantle, og er ikke noe luftslott.

Jeg antar at du refererer til minimums oppdaterings hastigheten på skjermen.

Og ja, selvsagt er en i5 bedre enn en fx 8350 på det, den har jo høyere enkel tråds hadtighet.

[HKS]

Hva grafikk kort med prosessering angår så ser jeg frem til å lese om hva som kommer til å skje med HSA.

Vi får se, jeg er ikke like optimistisk til HSA. Cache coherence på GPU er etter min mening en dårlig ide. Å programmere for en GPU er allerede fundamentalt forskjellige fra å programmere for en CPU.

 

Uansett ser jeg på Mantle som et steg i riktig retning siden den blir åpen til forskell fra CUDA.

Hvis den noen gang blir åpen. Jeg misstenker at Mantle er død og begravet den dagen DX12 er public.

 

 

 

Jeg er fullt klar over at hypertråder dreier seg om at man simpelthen bytter catchen (hva nå det blir på norsk) mens en annen oppgave blir gjort og at det derfor ikke blir gjort to oppgaver på samme tid, og ja, det er lurt, du slipper å laste ut informasjon fra catchen til ram fra den første oppgaven og fra ram til catchen for den andre for å bytte mellom oppgaver slik du må med en vanlig kjerne.

Du trenger ikke å bytte ut innholdet i cachen for å bruke HT. Begge de virtuelle CPU'ene kan ha data i cache samtidig. Det HT handler om er å dele eksekveringsresurser. En Haswell-kjerne kan eksekvere 8 operasjoner i parallell (8 ekekveringsporter)

 

Men fordi prosessoren kun kan *arbeide* med en oppgave (selv om den kan ha en annen oppgave på vent i catchen mens den venter på nødvendig informasjon eller på at den andre oppgaven blir ferdig) så vil de likevel forsinke hverandre litt.

Alle moderne prosessorer i dag har såkalte superscalar pipeline som gjør at prosessoren gjør mange oppgaver i parallell.

 

Så ytelsen på den enkelte tråden sett utenfra på to tråder på en enkel intel prosessor vil vise en svært rask tråd mens den andre er tom men de to trådene vil likevel ikke yte like bra som to enkel kjerner fra amd i en amd modul når både intel kjernen og amd modulen har to fulle tråder.

Du har nok misforstått litt hvordan en moderne CPU fungerer. Det som teller her er hvor mange instruksjoner i sekundet (IPS) prosessoren klarer å prosessere. Her er det et veldig komplisert blide. Jeg har dessverre ikke tid til å forklare alt, men parametere som er viktig er hvor god prosessoren er til å dekode instruksjoner, hvor effektiv minne hierarkiet er, cache prefetching, etc. Her er rett og slett Intel sine prosessorer i en helt annen liga en AMD.

 

Disse prossessorene er flinke på forskjellige ting.

Det er selvsagt mulig å plukke noen spesielle test case, men i de fleste tilfeller er Intel-prosessoren raskere. Som en bonus så bruker den også mye mindre strøm på å løse oppgaven.

 

Ps. En intel kjerne er ikke 1.5 x en amd kjerne men nermere 1.4, men det avhenger av om det dreier seg om reelle tall eller flyttall, og om det er enkel presisjon eller dobbel presisjon det dreier seg om.

Den generaliseringen stemmer nok ikke, da det i praksis er veldig mye mer en teoretisk integer eller float ytelse man snakker om.

[efikkan]

Tja, de fleste "vanlige" tester har neppe særlig mange andre programmer enn selve testen kjørende i bakgrunnen.

Ja det er riktig. Alt for få benchmarker bruker realistisk last. F.eks. folk avslutter ikke nettleseren med 20 faner når de skal spille, så sitter det ørten sider med JavaScript og Flash og gnurer på CPUen, sammen med kanskje Skype, Spotify, antivirus osv. Disse kan påvirke gjenomsnittlig ytelse litt, men de påvirker latency ennå mer, siden Windows og de fleste Linux-distroer er ikke en real-time kernel, som gjør at prosesser kan bli forstyrret av andre. Flere kjerner hjelper på med å "isolere" spill når de kjører, så tanken er riktig så langt.

 

Men den totale ytelsen til f.eks. en i5-4690K er i praksis totalt litt bedre enn en FX-8350. Som du har nevnt har Intel cirka en teoretisk ytelse på ~1.5x per kjerne i ren integer-ytelse, men forskjellen blir faktisk nærmere en faktor på 2 i praksis når det inkluderer overhead fra threading/scheduling og Intels bedre prefetcher. Sannheten er dessverre at AMDs kjerner er for svake til å kunne veie opp med flere kjerner.

 

De fleste spillere som lager sin egen PC prøver jo å unngå bloatware som pesten. Men når det er mange prosesser (andre en de som har med OpenCL, OpenGL og directx å gjøre) så er det en fordel med flere tråder siden det gir flere forskjellige "køer" som oppgavene kan fordeles på uten at de kommer i veien for hverandre.

Den her forstod jeg ikke.

 

Se forøvrig det HKS skrev om HT.

 

Jeg antar at du refererer til minimums oppdaterings hastigheten på skjermen.

Og ja, selvsagt er en i5 bedre enn en fx 8350 på det, den har jo høyere enkel tråds hadtighet.

Kan du forklare hva du mener her?

[Domaldel]

 

Hva grafikk kort med prosessering angår så ser jeg frem til å lese om hva som kommer til å skje med HSA.

Vi får se, jeg er ikke like optimistisk til HSA. Cache coherence på GPU er etter min mening en dårlig ide. Å programmere for en GPU er allerede fundamentalt forskjellige fra å programmere for en CPU.

 

Uansett ser jeg på Mantle som et steg i riktig retning siden den blir åpen til forskell fra CUDA.

Hvis den noen gang blir åpen. Jeg misstenker at Mantle er død og begravet den dagen DX12 er public.

 

 

 

Jeg er fullt klar over at hypertråder dreier seg om at man simpelthen bytter catchen (hva nå det blir på norsk) mens en annen oppgave blir gjort og at det derfor ikke blir gjort to oppgaver på samme tid, og ja, det er lurt, du slipper å laste ut informasjon fra catchen til ram fra den første oppgaven og fra ram til catchen for den andre for å bytte mellom oppgaver slik du må med en vanlig kjerne.

Du trenger ikke å bytte ut innholdet i cachen for å bruke HT. Begge de virtuelle CPU'ene kan ha data i cache samtidig. Det HT handler om er å dele eksekveringsresurser. En Haswell-kjerne kan eksekvere 8 operasjoner i parallell (8 ekekveringsporter)

 

Jeg snakker ikke om å bytte ut data i catchen, ben å bytte selve catchen.

Jeg må innrømme at informasjonen min om cpu arkitektur nok er for gammel til å si noe spesifikt om haswell eller andre nyere cisk cpuer)

Men slik jeg forstår det på en risk cpu så aktiviserer man simpelthen enn annen catch (eller flere catxher) når man setter en tråd på vent slik at statusen på xpuen for den tråden simpelthen fryses mens den andre tråden jobber.

Cpuen trenger litt tid på å bytte mellom oppgaver likevel og kan ikke gjøre det f. eks. mens den er i prosessen med å flytte data til en catch.

Men dette er likevel langt raskere enn å fysisk flytte data til å fra ram for å bytte data på catchen som man må gjøre på en prosessor uten hypertråder.

 

Men fordi prosessoren kun kan *arbeide* med en oppgave (selv om den kan ha en annen oppgave på vent i catchen mens den venter på nødvendig informasjon eller på at den andre oppgaven blir ferdig) så vil de likevel forsinke hverandre litt.

Alle moderne prosessorer i dag har såkalte superscalar pipeline som gjør at prosessoren gjør mange oppgaver i parallell.

 

Ja, greit...

Det stemmer for så vidt.

Men vi snakker likevel om en sammensatt kode.

Ett sett med instrukser som blir gitt på en gang, som blir satt i gang på en gang og deler resurser i varierende grad på forskjellige steg i prosessen med å bearbeide dataen som cpuen ble gitt.

Det er kanskje åtte forskjellige oppgaver på et vis, men det er likevel kun en kommando, er det ikke?

Jeg trenger ennå å lese mere om dette temaet...

 

Så ytelsen på den enkelte tråden sett utenfra på to tråder på en enkel intel prosessor vil vise en svært rask tråd mens den andre er tom men de to trådene vil likevel ikke yte like bra som to enkel kjerner fra amd i en amd modul når både intel kjernen og amd modulen har to fulle tråder.

Du har nok misforstått litt hvordan en moderne CPU fungerer. Det som teller her er hvor mange instruksjoner i sekundet (IPS) prosessoren klarer å prosessere. Her er det et veldig komplisert blide. Jeg har dessverre ikke tid til å forklare alt, men parametere som er viktig er hvor god prosessoren er til å dekode instruksjoner, hvor effektiv minne hierarkiet er, cache prefetching, etc. Her er rett og slett Intel sine prosessorer i en helt annen liga en AMD.

 

Jeg tror ikke jeg er helt på gjordet her.

Men det høres ut som jeg kan lære av deg selv om jeg fremdeles er uenig.

Så slår gjerne av en prat når du har mere tid.

 

Disse prossessorene er flinke på forskjellige ting.

Det er selvsagt mulig å plukke noen spesielle test case, men i de fleste tilfeller er Intel-prosessoren raskere. Som en bonus så bruker den også mye mindre strøm på å løse oppgaven.

 

Vel, jeg vil likevel påstå at bruks mønsteret mitt passer bedre for den prosessoren enn en fire kjernes intel prosessor.

Og at det slett ikke er så stor forskjell som du vil ha det til.

 

Ps. En intel kjerne er ikke 1.5 x en amd kjerne men nermere 1.4, men det avhenger av om det dreier seg om reelle tall eller flyttall, og om det er enkel presisjon eller dobbel presisjon det dreier seg om.

Den generaliseringen stemmer nok ikke, da det i praksis er veldig mye mer en teoretisk integer eller float ytelse man snakker om.

Ja, du har også rett i at det er langt mere som spiller inn.

AMD sliter virkelig med catch hastigheten f. eks, har dårligere minne kontrollerere, pluss, pluss pluss...

Men jeg vil likevel påstå at det tallet gjelder når prossessorene går det alle remmer og tøyler kan takle.

Det at den situasjonen der dette tallet kan gjelde i ikke oppstår så ofte for gjennomsnittsbrukeren er en annen sak.

[Domaldel]

 

Tja, de fleste "vanlige" tester har neppe særlig mange andre programmer enn selve testen kjørende i bakgrunnen.

Ja det er riktig. Alt for få benchmarker bruker realistisk last. F.eks. folk avslutter ikke nettleseren med 20 faner når de skal spille, så sitter det ørten sider med JavaScript og Flash og gnurer på CPUen, sammen med kanskje Skype, Spotify, antivirus osv. Disse kan påvirke gjenomsnittlig ytelse litt, men de påvirker latency ennå mer, siden Windows og de fleste Linux-distroer er ikke en real-time kernel, som gjør at prosesser kan bli forstyrret av andre. Flere kjerner hjelper på med å "isolere" spill når de kjører, så tanken er riktig så langt.

 

Men den totale ytelsen til f.eks. en i5-4690K er i praksis totalt litt bedre enn en FX-8350. Som du har nevnt har Intel cirka en teoretisk ytelse på ~1.5x per kjerne i ren integer-ytelse, men forskjellen blir faktisk nærmere en faktor på 2 i praksis når det inkluderer overhead fra threading/scheduling og Intels bedre prefetcher. Sannheten er dessverre at AMDs kjerner er for svake til å kunne veie opp med flere kjerner.

 

De fleste spillere som lager sin egen PC prøver jo å unngå bloatware som pesten. Men når det er mange prosesser (andre en de som har med OpenCL, OpenGL og directx å gjøre) så er det en fordel med flere tråder siden det gir flere forskjellige "køer" som oppgavene kan fordeles på uten at de kommer i veien for hverandre.

Den her forstod jeg ikke.

 

Se forøvrig det HKS skrev om HT.

 

Jeg antar at du refererer til minimums oppdaterings hastigheten på skjermen.

Og ja, selvsagt er en i5 bedre enn en fx 8350 på det, den har jo høyere enkel tråds hadtighet.

Kan du forklare hva du mener her?

20 faner!?!

Det er nesten ingenting. :-P

Selv er jeg ofte på omtrent 400 selv... :-/

(Jeg vet, kjempe uvane)

 

Når deg gjelder ytelse i spill så dreier det seg om enkelts tråds hastighet.

Hvis du har oppgave 1, 2, 3, og 4 som må skje i rekkefølge før gpuen kan forsette og oppgave A, B, C, D og E (i rekkefølge) som er urelatert så vil en intel cpu gjøre oppgave 1 til 4 raskere og så a til e raskere.

Tiden fra den får oppgaven til oppgaven er ferdig er mye kortere.

Men jeg tenker mere på totalt antall oppgaver som blir gjort, på spillet, nettleserene, den virtuelle maskinen, tor, spotify, andre vpaer, hjemmeserveren som serverer flere folk samtidig med mere.

Det blir en del ting.

[Domaldel]

Uff, begynner å gå litt rund for meg her...

Er sent og diskusjoner med for mange på en gang... > <

[IntelAmdAti]

 

 

Så gjenstår det å se om "freesync" er like bra som g-sync

 

Siden det har vært så lite info/tester av freesync, så er jeg automatisk skeptisk. Like skeptisk jeg var mot Mantle, og det hadde jeg tydeligvis god grunn til å være

Nvidias G-Sync works like a rocket

But with FreeSync and Analog Micro Devices

you can keep your "G's" in your pocket

and get those frames synced anywaises

Får vel vente på en av de store reviewsidene som f.eks anandtech og co for å vite fasiten. Om et par år

 

 

Jeg ser for meg at Freesync vil bli like bra eller bedre siden det blir integrert i en etablert standard. Nvidia sin løsning virket i starten mer som noe hjemmesnekring med oppgraderingskort til skjermer, de var først ute med et fungerende produkt og det fortjener de skryt for men AMD sin teknologi virker mer elegant og bedre gjennomført.

 

Dessuten tror jeg konsoller kan komme til å støtte Freesync, noe som vil være en stor fordel.

 

Men det blir interessant å lese om når det kommer.

[Andrull]

Nuvell... Ikke noe nytt at AMD kommer slentrende etter på teknologisiden da. Ikke noe negativt, da de som ikke fremmer fremskrittet hele tiden, ofte kan ta å skape rimelig gode og billige løsninger.

 

At Nvidia sin løsning ikke var like "elegant" er vel ikke så rart, når det ikke eksisterte noe lignende fra før. Trengte å få ut løsningen, uten at de trengte å måtte vente på at skjermprodusenter skulle implementere det fullt ut.

 

Pioneerende forbrukere på feltet har nok lite problem med å gjøre en så liten filleting selv.

 

Men joda, godt å høre at noen tar å utnytter DP sine muligheter, selv om det er lovlig sent implementert. Hadde de fått til en felles standard så hadde det dog vært konge.

 

Edit:

Det begynner å bli ganske vanlig for spillene å kunne dele opp oppgavene i flere parallelle tråder. Gjerne 3-4, men noen få opp mot 6-8 tråder. Og selv om det ikke belaster maksimalt, så funker det godt nok til å gi stabilt god ytelse.

Så det som virkelig har noe å si er en kombinasjon av god multitrådytelse og singeltråd. Både for realistisk last i bakgrunnen, men også at hver enkelt tråd ikke holder igjen informasjonen, slik at resten av maskinen må vente. Da dundrer minimum-FPS i bånn.

 

Er det for få tråder/kjerner, så vil plutselig en kjerne kunne være opptatt med noe annet, som igjen betyr at visse oppgaver i spillet ikke lengre kan kjøre parallelt, men må vente på at noe annet blir ferdig. Også nå vil minste-FPS falle en god del. Helt typisk at dette skjer når det teller mest.

 

Intel er klart best på enkelttrådytelse, men også på nivå med AMD på multitrådytelse, spesielt med HT, og ikke sjokkerende så vil denne fordelaktive kombinasjonen gjøre det sterkt i spill.

 

Dog, nå begynner jo også 6-kjerner med HT å bli ganske "billig" fra Intel, så kanskje verdt å vurdere om man vil ha pose og sekk.

Endret 21. oktober 2014 av Andrull