Gå til innhold

AMD har lansert kraftkaren «Fury X» og nye Radeon-kort


Anbefalte innlegg

Videoannonse
Annonse

Du mener vel at ingen Windows-versjoner er slik ;)

 

Nå har vel alle Windows-utgaver hatt en del barnesykdommer så jeg forstår godt ønsket med å vente litt.

 

Og i fare for å spore av helt så har det både ulemper og fordeler å gå over så fort som mulig til et nytt os.

Personlig liker jeg at trusselbildet blir noe mindre , malwaren må ofte finne nye måter å fungere på og man kan "kanskje" få langt bedre ytelse om Os'et er finpusset i forhold til forrige versjon.

 

Både W 8 og 10 ser ut til å ha en del forbedringer i forhold til bakoverkompabilitet med eldre spill , bedre ytelse og ikke minst bedre system sikkerhet...

 

Så tilbake til topic...

 

Nizzen : Kan faktisk støtte den linken du ga , jeg har også erfart at en del spill rett og slett yter bedre nå enn for et år siden , det tyder i det minste på at driverne har blitt mer modne og at Mantle / DX 12 nå begynner å få den finpussen som gjør at vi kanskje ser en vesentlig forbedring i forhold til de tidligere versjonene av Windows og DX , så spørs det om sluttproduktet vi får levert blir en vesentlig forbedring i forhold til fps ( Amd har faktisk en god del å gå på i følge flere erfarne forumbrukere som har påpekt problemene med dagens drivere og utnyttelse av hardware ).

Lenke til kommentar

Jeg fikk et svar angående D3D12 og bl.a draw calls fra en spill utvikler, Sebastian Aaltonen. Lead graphics programmer bak Trials Fusion bl.a. For dem som er interessert.

 

It depends heavily on engine architecture. Some engines give technical artists lots of freedom to do whatever they want. Technical artists can freely configure rendering passes and shaders with visual flow graph editors. This kind of tools produce a huge permutation of shaders and lots of different materials with various inputs. It is difficult to automatically batch data sets like this. If your tools and engine architecture prioritizes technical artist productivity, ease of prototyping and iteration time over technical factors (such as the count of draw calls, count of rendering passes and count of shader permutations), DirectX 12 is a huge improvement over DirectX 11.

Some engine pipelines are heavily programmer oriented. All data flow is highly optimized (bit packed optimized data) and rendering passes are tightly coupled together to reduce the extra memory traffic. There's not much freedom for artists to add new rendering passes, modify data layouts or add completely new kinds of shaders. Pipelines like this tend have small amount of shader permutations (usually physically based) and are using deferred rendering (and other techniques that expose some limits to the input and output data and draw call ordering). Lighting and post processing is nowadays usually done with (highly optimized) compute shaders (authored solely by programmers). It is much easier to batch pipelines like this. In some extreme cases a pipeline like this doesn't need more than a single draw call to render the entire visible scene. In this extreme case DirectX 12 cheap draw calls do not bring much (if any) performance gains. Other DirectX 12 features such as ExecuteIndirect, asynchronous compute, ROV and conservative rasterization however might be very useful. 

DirectX 12 is a huge improvement for console porting in general. Finally we can do low level GPU memory/resource management on PC. We can use our own optimized resource management systems that are hand optimized for our engine's data streaming model. With DirectX 11 you had to pray that the driver was clever enough to do the right thing. This often resulted in stuttering and random frame rate spikes on PC. Players complained bad porting, and GPU manufacturers had to create case by case optimizations to their drivers. graphics programmers had to maintain and optimize two completely different resource management models. Comparing DirectX 11 to Java is a nice way to explain the problems: you have no way to optimize the memory layout, garbage collection causes random stalls and each virtual machine behave differently (regarding to these two). A common tip to make garbage collected languages run a game smoothly is to avoid memory allocations alltogether when a level is running. Similarly GPU manufacturers recommend you to create all your DirectX 11 graphics resources at loading time, because the driver will cause stalls otherwise.

 

 

  • Liker 1
Lenke til kommentar

Malvado:

Ingen har vel bestridet at et nyere OS inneholder forbedringer. Men som Efikkan også sier er det mange årsaker til at man ønsker å vente.

 

Jeg ser heller ingen grunn til at DX12 ikke skal kunne kjøre på Windows 7 så lenge det er et supportert OS og ikke har nådd EOL, dette er vel i beste fall en kunsting sperre som vi har sett fra Microsoft ved flere annledninger.

 

Det blir spennende å se hvordan de gjør dette med Windows 10 som da skal være siste versjonen av Windows. Får de det da "mirakuløst" til å fungere med DX13 osv.

 

TKongen:

Hvis du ikke er klar over det har man kunnet installere forskjellige DX versjoner på samme Windows versjon. Feature Packs eksisterer også. Ser ikke helt denne "pakke" greia du prøver å skvise det inn i.

Endret av Theo343
Lenke til kommentar

@Theo343

Jeg vet jo at hovedgrunnen for at DX12 kommer i windows 10 ikke er tekniske årsaker. De kunne fint lagt det til i Windows 7. Microsoft ønsker jo svært høy adopsjon av Win 10 og det raskt. Det viser jo avtaler med Tencent ganske tydelig f.eks. De er MS som vil selge Win 10 som en pakke. De vil at du skal ha hele win 10. Det er de som vil prøve å gjøre OSet mer universalt og likt for alle. Det er ikke noe jeg vil ha inn, det er MS.

 

Det er jo absolutt en av mange mer mainstream avgjørelser fra MS, for å konkurrere bedre i dagens marked. Jeg bruker Windows 10 beta selv. Selv i beta så fungerer det meste veldig bra (har NVIDIA, og de er på sin andre win 10 driver nå, så det har hjulpet på spilling. Det er der jeg har hatt problemer med win 10.) Det er helt klart flere fordeler med å oppgradere en eventuelle ulemper. Dessuten er det jo bare å vente et par måneder med tanke på ting som utgjør et større utslag på opplevelsen som er dårlig. Innen den tid har det nok ikke akkurat kommet ut noen store DX12 titler. Du har jo og 1 år på deg til å oppgradere.

Lenke til kommentar

Malvado:

Ingen har vel bestridet at et nyere OS inneholder forbedringer. Men som Efikkan også sier er det mange årsaker til at man ønsker å vente.

 

Jeg ser heller ingen grunn til at DX12 ikke skal kunne kjøre på Windows 7 så lenge det er et supportert OS og ikke har nådd EOL, dette er vel i beste fall en kunsting sperre som vi har sett fra Microsoft ved flere annledninger.

 

DX12 er vistnok knyttet opptil WDDM 2.0. Det er nok da ikke en liten oppgave å implementere en ny driver modell i eldre Windows versjoner, spesielt mtp et hav av drivere som fordelsvis skal fortsette å fungere på PC'er i de tusen hjem og ikke minst i bedrifter.

DX12 kunne alternativt ha blitt overført til Windows 7+8 i en eller annen form, men spill utviklerne måtte isåfall ta høyde for at brukeren ikke har WDDM 2.0.

 

WDDM 2.0 is based around enabling DirectX 12, adding the necessary features to the kernel and display drivers in order to support the API above it. Among the features tied to WDDM 2.0 are DX12’s explicit memory management and dynamic resource indexing, both of which wouldn’t have been nearly as performant under WDDM 1.3. WDDM 2.0 is also responsible for some of the baser CPU efficiency optimizations in DX12, such as changes to how memory residency is handled and how DX12 applications can more explicitly control residence.

 

Lenke til kommentar

Some engines give technical artists lots of freedom to do whatever they want. Technical artists can freely configure rendering passes and shaders with visual flow graph editors. ... It is difficult to automatically batch data sets like this. If your tools and engine architecture prioritizes technical artist productivity, ease of prototyping and iteration time over technical factors (such as the count of draw calls, count of rendering passes and count of shader permutations), DirectX 12 is a huge improvement over DirectX 11.

 

Some engine pipelines are heavily programmer oriented. All data flow is highly optimized (bit packed optimized data) and rendering passes are tightly coupled together to reduce the extra memory traffic. There's not much freedom for artists to add new rendering passes, modify data layouts or add completely new kinds of shaders...

Ja her kommer de inn på det jeg snakker om.

 

I programvareutvikling er oftest abstraksjon og optimalisering lite forenlig, og det sier seg selv at helt generiske spillmotorer som har essensielt abstrahert bort all programmering vil være lite optimaliserte i utgangspunktet. Det jeg snakket om tidligere om "dårlig kodet" var blant annet dette, i tilegg til gamle ineffektive arkitekturer. I tillegg har vi spillmotorer som er mer halvfabrikat og noen som er ennå enklere, og selvsagt mange grader mellom der. Ofte er også generiske spillmotorer langt mindre optimalisert enn spesialiserte spillmotorer, f.eks. til førstepersonsspill.

 

Abstraherte spillmotorer har absolutt sin plass, og tillater artistisk frihet uten et helt team av programmeringseksperter. Fjerning av API-overhead vil selvsagt hjelpe en del, men stort sett så er vel ikke slike spill de tyngste stortitlene fra før.

 

Det er viktig å huske på at hvis API-overheaden er et problem så er koden for ineffektiv i utgangspunktet, og da er det ennå mer å hente på mer effektive måter å bruke GPUen på. For store komplekse spillmotorer så er der faktisk en annen faktor som kan være ennå større; abstraksjon og innkapsling i selve spillmotordesignet. Hvis du skal tegne 10.000 objekter, og for hvert objekt skal du gjøre en drøss med funksjonskall før du kommer til API-kallene så er det på tide å bytte ut hele renderingen. API-overheaden blir da bare et symptom på et større problem som er et ineffektivt design. Alle spillmotorer burde vært designet rundt hvordan en GPU utnyttes optimalt, ikke etter en "perfekt" hierarkisk objektmodell i følge læreboken.

 

Grunnen til at jeg påpeker alt dette er at jeg ønsker å gi folk realistiske forventninger om hva Direct3D 12 kommer til å gjøre for spill. De store spilltitlene kommer ikke til å få enorme forbedringer, men det avgjørende blir hvorvidt spillene optimaliseres for effektiv GPU-bruk. Mange tror at optimaliseringer og effektivt design blir mindre viktig med kraftig maskinvare, men det er direkte feil. Til kraftigere maskinvare vi får, til større blir gapet mellom programvaren som utnytter den godt og den som utnytter den dårlig. Jeg vet at maskinvaren er i stand til å klare så mye mer, og testet selv for tre år siden med et GTX 680 som er i stand til å tegne 8 millioner polygoner i >60 Hz, 1920x1200 med 8x MSAA. Ingen spill i dag er i nærheten av det detaljnivået, og jeg sier dette for at folk skal forstå potensialet som er å hente ut. Det er snakk om en faktorforskjell på god og dårlig optimalisert kode.

Lenke til kommentar

Da var reviews av AMD sin Fury X ute:
http://www.techspot.com/products/graphics-cards/amd-radeon-r9-fury-x.120324/

 

Både i min fps og avg fps blir den slått i 1080p (uten at det betyr noe), den taper og såvidt til 980 Ti ved 1440/1600p. Ved 2160p er forskjellen i de fleste spill eldig liten, men GTX 980 Ti beholder fortsatt en liten egde over Fury X. Kortet bruker ellers kun litt mer strøm enn GTX 980 Ti, og er derfor ikke på noen måte et strømsluk som de andre Radeon modellene. Temperaturer er og veldig gode. Selvfølgelig hjulpet av vannkjølingen. Ulempen er jo at denne type kort kommer med vannkjøling. Alt er så konsentrert på et sted, så det er nok vanskelig med luftkjøler. Hvis du har plass til det i kabinettet derimot er det jo en god kjøleløsning som holder kortet til under 65 grader. Ellers så jeg at du er låst ute fra å regulere volt, og en nettside sa at endring i frekvens og power target ga lite utslag. Altså virker det vanskelig å overklokke kortet.

 

Ikke overraskende stemmer IKKE tallene AMD lanserte som viser at Fury X er bedre enn GTX 980 Ti. Fury X kommer dermed i litt samme kategori som R9 390X mot GTX 980. Likevel er det et mye bedre kjøp da både strømforbruk og temperaturer er mye bedre. Plass kan bli problematisk pga vannkjøling. Spesielt hvis du har vannkjøling også til CPU. Kan se for meg litt økte problemer ved CF også. Fury X kan altså være et ganske bra kjøp. Likevel gir det ikke folk noen ekstra grunn til å kjøpe AMD. De stiller seg bare likt med NVIDIA, bare en stund etter at NVIDIA har hatt kortene ute. Lover ikke altfor bra for fremtiden hvis de har brukt så mye tid og penger på å lage disse toppkortene kun for å matche NVIDIA sitt forbruker kort i ytelse (Titan X er jo egentlig ikke et skikkelig forbruker kort og prisen for det til gaming er jo ganske ekstrem). 

 

Får se hvordan Fury Nano blir. Med tanke på strømbruken til Fury X er påstanden om bedre ytelse enn R9 290X med halve strømforbruket gjerne en tanke optimistisk. På den andre side viser nettsider som techpowerup at GTX 970 bruker under halvparten så mye strøm som R9 290X med lik fps. Hvis de måler på samme måte som de gjør, så vil det være mulig å komme nær den påstanden hvertfall.

Lenke til kommentar

 

Malvado:

Ingen har vel bestridet at et nyere OS inneholder forbedringer. Men som Efikkan også sier er det mange årsaker til at man ønsker å vente.

 

Jeg ser heller ingen grunn til at DX12 ikke skal kunne kjøre på Windows 7 så lenge det er et supportert OS og ikke har nådd EOL, dette er vel i beste fall en kunsting sperre som vi har sett fra Microsoft ved flere annledninger.

DX12 er vistnok knyttet opptil WDDM 2.0. Det er nok da ikke en liten oppgave å implementere en ny driver modell i eldre Windows versjoner, spesielt mtp et hav av drivere som fordelsvis skal fortsette å fungere på PC'er i de tusen hjem og ikke minst i bedrifter.[/size]

 

DX12 kunne alternativt ha blitt overført til Windows 7+8 i en eller annen form, men spill utviklerne måtte isåfall ta høyde for at brukeren ikke har WDDM 2.0.[/size]

 

 

WDDM 2.0 is based around enabling DirectX 12, adding the necessary features to the kernel and display drivers in order to support the API above it. Among the features tied to WDDM 2.0 are DX12’s explicit memory management and dynamic resource indexing, both of which wouldn’t have been nearly as performant under WDDM 1.3. WDDM 2.0 is also responsible for some of the baser CPU efficiency optimizations in DX12, such as changes to how memory residency is handled and how DX12 applications can more explicitly control residence.

Det forklarte saken godt og jeg fryktet i grunn at det kunne være noe slik. Takker.

Endret av Theo343
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...