Gå til innhold

DirectX 12 demonstrert med bedre ytelse og lavere strømforbruk


Anbefalte innlegg

Videoannonse
Annonse

Er ikke OpenGL mer relevant enn Mantle når det gjelder som et alternativ til DirectX?

Ja OpenGL er mye mer relevant enn Mantle, siden OpenGL er allerede utbredt og har langt større forbedringer enn det Mantle tilbyr. OpenGL har allerede API-kall med lavere overhead, bla. multibind og rendering av flere meshes, har bindless graphics og direkteaksess til teksturer gjennom pekere i shadere som eliminerer API-kall, og har nå denne uken også standardisert direct state access som er videre med på å redusere overhead. Mantles forbedringer er minimale i sammenligning.

 

 

De fleste moderne nettlesere har også fått støtte for hardware-akselerering av grafikk. Er dette basert på DirectX, eller er det noe simplere?

WebGL er egentlig basert på et subsett av OpenGL ES 2.0 (som igjen er et subsett av OpenGL). WebGL-implementasjonen til IE11 bruker forøvrig også Direct3D, som er naturlig siden sentrale deler av OpenGL og Direct3D er svært likt.

 

Det skal sies at ulike nettlesere bruker ulik grad av akselerasjon gjennom GDI for eldre IE, DirectX i nyere IE, og tilsvarende semi-akselerasjon i GTK for Firefox og delvis OpenGL for Chrome.

  • Liker 2
Lenke til kommentar

 

Er ikke OpenGL mer relevant enn Mantle når det gjelder som et alternativ til DirectX?

Ja OpenGL er mye mer relevant enn Mantle, siden OpenGL er allerede utbredt og har langt større forbedringer enn det Mantle tilbyr. OpenGL har allerede API-kall med lavere overhead, bla. multibind og rendering av flere meshes, har bindless graphics og direkteaksess til teksturer gjennom pekere i shadere som eliminerer API-kall, og har nå denne uken også standardisert direct state access som er videre med på å redusere overhead. Mantles forbedringer er minimale i sammenligning.

 

 

De fleste moderne nettlesere har også fått støtte for hardware-akselerering av grafikk. Er dette basert på DirectX, eller er det noe simplere?

WebGL er egentlig basert på et subsett av OpenGL ES 2.0 (som igjen er et subsett av OpenGL). WebGL-implementasjonen til IE11 bruker forøvrig også Direct3D, som er naturlig siden sentrale deler av OpenGL og Direct3D er svært likt.

 

Det skal sies at ulike nettlesere bruker ulik grad av akselerasjon gjennom GDI for eldre IE, DirectX i nyere IE, og tilsvarende semi-akselerasjon i GTK for Firefox og delvis OpenGL for Chrome.

så alle CPU begrensa spill kan få mer en 2x ytelse om de bare går over til OpenGL? Mantle kan ihvertfall teoretisk gi 2x ytelse, jeg synes ikke det høres lite ut. kan ikke så mye om OpenGL men Mantle skal ihvertal ha bedre multi-GPU støtte enn DirectX 11 i tilegg at man har større rom til å optimalisere

Lenke til kommentar

så alle CPU begrensa spill kan få mer en 2x ytelse om de bare går over til OpenGL? Mantle kan ihvertfall teoretisk gi 2x ytelse, jeg synes ikke det høres lite ut. kan ikke så mye om OpenGL men Mantle skal ihvertal ha bedre multi-GPU støtte enn DirectX 11 i tilegg at man har større rom til å optimalisere

Jeg vet ikke hvor du får 2x bedre ytelse fra, men det er en kjent sak at Mantles optimaliseringer hjelper mer til svakere CPUen er, dvs. det helper en AMD-APU mye mer enn en kraftig i5/i7. Når det gjelder den typen optimaliseringer som Mantle har så får Direct3D 12 det, og OpenGL har allerede tilsvarende. Dette er primært snakk om optimaliseringer som hjelper mest for svakere CPUer for alle tre APIene. Mantle gir altså ikke skaleringsfordeler oppover.

 

På toppen av dette tilbyr OpenGL allerede flere optimaliseringer, deriblant bindless graphics og bindless textures som formidabelt kan hjelpe ytelsen med tung GPU-last med mange aktive objekter, slik som partikler (røyk, flammer, osv), vegetasjon eller andre mengder av enkeltobjekter på skjermen. Dette hjelper både trege og rasker CPUer ved at noen API-kall byttes ut med raskere API-kall, mens andre kuttes helt ut og logikken flyttes direkte over til GPUen.

La meg ta et konkret eksempel for å forklare:

La oss si jeg skal tegne en scene med 10.000 små busket i et terreng. Hver enkelt busk bruker én av 32 ulike buskteksturer. I konvensjonell rendring (OpenGL, Direct3D, osv.) må jeg for hver busk binde en tekstur til en texture unit (som igjen betyr at jeg reserverer en del av GPUens cache til teksturen).

Dette betyr at jeg for hvert objekt kjører en "unødvendig" glBindTexture()-funksjon.

Med bindless textures kan jeg på forhånd knytte tusenvis av teksturer til pekere som jeg senere kan hente direkte i shader-koden. Dermed kan jeg elegant hoppe over bindingen for hvert objekt, og legge til en liten kodesnutt inne i shader-koden som leser ut fra objektet hvilken av de 32 teksturene jeg skal bruke.

I tillegg til at jeg nå har spart 10.000 kostbare API-kall, har vil jeg også oppnå en optimalisering på GPU-siden. Moderne GPUer har nemlig et intelligent cache-system som gjør at når jeg kjører koden vil den effektivt utnytte L2-cache til å laste de riktige teksturene fortløpende, i stedet for at cachen reserveres for én tekstur, og at denne dyttes ut og lastes på nytt for hvert bidige element som skal tegnes. Bindless graphics fungerer på tilsvarende måter for meshes.

 

Problemet med bindless graphics og textures er driverstøtten. Bindless textures er allerede offisielt standardisert fungerer allerede med både Nvidia og AMD, mens AMD mangler en del på de øvrige bindless graphics-utvidelsene. Gevinsten av disse utvidelsene kan være over 50% ytelseøkning ved bruk av svært mange elementer.

 

Dette ble kanskje noe teknisk, men det er bare å spørre om du vil vite mer.

  • Liker 7
Lenke til kommentar

Anbefaler å lese denne artikkelen fra Tomshardware angående Mantle.

How does Mantle supposedly improve compared to OpenGL and DirectX?
Mantle is associated with the phrases "low-level" and "closer to the metal". But what does that actually mean? In simple terms, the answer is minimalism. It's smaller, simpler, and consequently faster than DirectX 11 and OpenGL. AMD's new API purportedly makes fewer assumptions about how developers want to render a given scene. This puts more control of resources in the developer's hands, instead of the API's, allowing for better optimization.


Mange påstander om Mantle , så da er det greit å gå litt i dybden og komme til sin egen konklusjon isteden for noen som har enten misforstått eller har en bias rettet mot et produkt eller software.

 

Kan ikke si noe annet enn at det er en meget bra artikel fra Tomshardware som bør leses.

Lenke til kommentar

 

så alle CPU begrensa spill kan få mer en 2x ytelse om de bare går over til OpenGL? Mantle kan ihvertfall teoretisk gi 2x ytelse, jeg synes ikke det høres lite ut. kan ikke så mye om OpenGL men Mantle skal ihvertal ha bedre multi-GPU støtte enn DirectX 11 i tilegg at man har større rom til å optimalisere

Jeg vet ikke hvor du får 2x bedre ytelse fra, men det er en kjent sak at Mantles optimaliseringer hjelper mer til svakere CPUen er, dvs. det helper en AMD-APU mye mer enn en kraftig i5/i7. Når det gjelder den typen optimaliseringer som Mantle har så får Direct3D 12 det, og OpenGL har allerede tilsvarende. Dette er primært snakk om optimaliseringer som hjelper mest for svakere CPUer for alle tre APIene. Mantle gir altså ikke skaleringsfordeler oppover.

 

På toppen av dette tilbyr OpenGL allerede flere optimaliseringer, deriblant bindless graphics og bindless textures som formidabelt kan hjelpe ytelsen med tung GPU-last med mange aktive objekter, slik som partikler (røyk, flammer, osv), vegetasjon eller andre mengder av enkeltobjekter på skjermen. Dette hjelper både trege og rasker CPUer ved at noen API-kall byttes ut med raskere API-kall, mens andre kuttes helt ut og logikken flyttes direkte over til GPUen.

La meg ta et konkret eksempel for å forklare:

La oss si jeg skal tegne en scene med 10.000 små busket i et terreng. Hver enkelt busk bruker én av 32 ulike buskteksturer. I konvensjonell rendring (OpenGL, Direct3D, osv.) må jeg for hver busk binde en tekstur til en texture unit (som igjen betyr at jeg reserverer en del av GPUens cache til teksturen).

Dette betyr at jeg for hvert objekt kjører en "unødvendig" glBindTexture()-funksjon.

Med bindless textures kan jeg på forhånd knytte tusenvis av teksturer til pekere som jeg senere kan hente direkte i shader-koden. Dermed kan jeg elegant hoppe over bindingen for hvert objekt, og legge til en liten kodesnutt inne i shader-koden som leser ut fra objektet hvilken av de 32 teksturene jeg skal bruke.

I tillegg til at jeg nå har spart 10.000 kostbare API-kall, har vil jeg også oppnå en optimalisering på GPU-siden. Moderne GPUer har nemlig et intelligent cache-system som gjør at når jeg kjører koden vil den effektivt utnytte L2-cache til å laste de riktige teksturene fortløpende, i stedet for at cachen reserveres for én tekstur, og at denne dyttes ut og lastes på nytt for hvert bidige element som skal tegnes. Bindless graphics fungerer på tilsvarende måter for meshes.

 

Problemet med bindless graphics og textures er driverstøtten. Bindless textures er allerede offisielt standardisert fungerer allerede med både Nvidia og AMD, mens AMD mangler en del på de øvrige bindless graphics-utvidelsene. Gevinsten av disse utvidelsene kan være over 50% ytelseøkning ved bruk av svært mange elementer.

 

Dette ble kanskje noe teknisk, men det er bare å spørre om du vil vite mer.

 

2x ytelse får jeg fra egene tester jeg gjorde lenge siden via en CPU orientert Mantle test med navn "Star Swarm Stress Test" som man kan finne på steam

 

gjorde en ny test nå:

CPU: AMD FX-8350

GPU: AMD Radeon 7970

Setting: Extreme

Senario: RTS

Timed Run

 

gjennomsnittelig FPS med DirectX: 6.62

gjennomsnittelig FPS med Mantle: 30.31

 

det ble vist 5x ytelse, tviler litt på at man får se slike numere i GPU begrensa spill

Lenke til kommentar

Bare så det er sagt, bindless graphics gir ~7.5x bedre VBO(Vertex Buffer Object)-ytelse, så det er lett å lage en demo som mangedobler ytelsen. Men 7.5x bedre VBO-ytelse betyr kanskje ~50+% bedre total ytelse i reelle spill. Det samme gjelder benchmarks du ser om Mantle, de vil overdrive ett enkelt aspekt for å vise forskjell.

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...