AMD släpper Catalyst 15.7 WHQL med stöd för DirectX 12 och Crossfire för Freesync

Permalänk
Medlem
Skrivet av SeF.Typh00n:

Visst är det så, men problemet är att det är ju helt fel tänk i AMDs situation. Det är något dom verkligen inte har råd med, framförallt inte med tanke på hur länge dom suttit och ruvat på Mantle. Vilket gör att en hel generation av grafikkort har suttit i baksätet på DX11 och kommer göra väldigt länge till.

Nvidia lyckas prestera bra i både DX11 och DX12 så visst är det en brist på folk i AMDs drivrutinsavdelning.

Säger inte om det är rätt eller fel val men det är förståeligt att GCN och Dx11 inte spelar så optimalt med varandra medans GCN är grym på Dx12/Vulkan/Mantle. Det har med arkitekturen där GCN är grym på parallellitet, även tidiga GCN versioner. Dx11 var däremot rätt jävla kasst på parallellitet så blev inte en optimal blandning.
Fermi, Kepler och framför allt Tesla var lite motsatta där dem är starkare per tråd men lägre parallellism. Maxwell börjar närma sig en blandning mellan parallellism och Fermi/Kepler strukturen.
Sedan håller jag med om att Nvidia har låg overhead i Dx12, men det är inte i närheten utav GCN. Till och med 285 kan ju göra fler drawcalls än 980, speciellt med 4 kärnor där den leder med 17%. Mycket möjligt däremot att dem siffrorna ändras lite iom fler drivrutiner men GCN älskar verkligen Dx12

Visa signatur

Citera eller @philipborg om du vill att jag ska läsa dina svar.

Permalänk
Medlem

FRTC fungerade ju sådär för mig :/
Har cap'at fps vid 60 men dom enda programmen som det faktiskt fungerar i är Valley och 3DMARK. Alla spel rullar på som vanligt och ignorerar FRTC -.-

Någon som får det att fungera riktigt?

Visa signatur

Åbäke: R7 3700X | ASUS X470 Strix-F | EVGA GTX 1080 FTW | 32GB RAM | Custom Loop
HTPC: i7 7700K Delid | Noctua NH-U9B SE2 | MSI Z270M Mortar | GTX 1660 Super | 16GB RAM |
Konsoler: Xbox One X | Xbox 360 | Xbox | PS4 | PS3 | PS2 | Wii

Permalänk
Medlem

Trist att alla andra kort förutom R9 285 är låsta till en viss grad i VSR, testat 3200x1800 och funkar prima.

Visa signatur

EVGA RTX 3080 / 5800x / Gigabyte X570 I AORUS PRO WIFI / Ballistix 32GB 3200mhz / Corsair SF750 750W / Gigabyte 48" AORUS FO48U OLED 4K 120 Hz

Permalänk
Avstängd

23% boost i FC4 fury x
grymt

Visa signatur

Träna bort dyslexin. Ryzen 3600 - asus B350plus - Msi Vega56 - Acer 1440p 144hz - M.2 ssd - asus essence stx - Sennheiser hd600 - Corsair 750w - 16gb ram 3ghz - atcs 840 - luftkylt - Felsökning? (Lär dig Googla)

Permalänk
Medlem
Skrivet av makarickiri:

FRTC fungerade ju sådär för mig :/
Har cap'at fps vid 60 men dom enda programmen som det faktiskt fungerar i är Valley och 3DMARK. Alla spel rullar på som vanligt och ignorerar FRTC -.-

Någon som får det att fungera riktigt?

Fungerar inte hos mig heller.

Visa signatur

R7-3700X, B450M Mortar MAX, 32GB DDR4 @ 3200, RTX 2080, Corsair CX650M Rev2

Permalänk
Medlem

Är det någon annan som har problem att installera nya uppdateringen eftersom den inte är en "Signerad Drivrutin" enligt windows och då inte funkar korrekt....?

Visa signatur

i5 2500K|Vengeance 8Gb|Sabertooth P67|GTX 980Ti|Corsair AX1200|Force GT 120Gb|5TB lagring|Asus Xonar STX II

Permalänk
Avstängd
Skrivet av roxkz:

Det var verkligen på tiden, herrejävlar vad de har släpat fötterna efter sig. :\

Jag antar att du har fel i din signatur då eftersom du verkar ha väntat på drivrutinen:-)

Visa signatur

FD refine S Msi x99s sli plus 5930k@4400mhz NH-D14 Asus GTX 980 Strix SLI 16gb gskill ripjaws ddr4 3ghz Os Samsung 950 pro 512gb NVME Spel samsung 840/850 evo/pro Win 10 Pro Corsair Ax850 Gold Asus PG278Q Rog Swift

Permalänk
Medlem

Så man måste ha windows 10 för att detta ska fungera felfritt, eller kan man med gott samvete installera denna nya drivrutinen med win 7?

Permalänk
Medlem
Skrivet av VideoyGTX:

Så man måste ha windows 10 för att detta ska fungera felfritt, eller kan man med gott samvete installera denna nya drivrutinen med win 7?

Pröva en uppdatering utan att avinstallera med DDU som jag gjorde. Jag sitter utan drivrutiner för tillfället...

Visa signatur

i5 2500K|Vengeance 8Gb|Sabertooth P67|GTX 980Ti|Corsair AX1200|Force GT 120Gb|5TB lagring|Asus Xonar STX II

Permalänk
Skrivet av VideoyGTX:

Så man måste ha windows 10 för att detta ska fungera felfritt, eller kan man med gott samvete installera denna nya drivrutinen med win 7?

För mig, med win 7 och Crossfire 290, gick det utmärkt att uppdatera.

Permalänk
Medlem
Skrivet av VideoyGTX:

Så man måste ha windows 10 för att detta ska fungera felfritt, eller kan man med gott samvete installera denna nya drivrutinen med win 7?

Nej du måste inte ha W10 för denna drivis. Bara att det är den första "riktiga"(WHQL) drivrutinen för W10.
Du kan med gott samvete installera den med W7

Visa signatur

Åbäke: R7 3700X | ASUS X470 Strix-F | EVGA GTX 1080 FTW | 32GB RAM | Custom Loop
HTPC: i7 7700K Delid | Noctua NH-U9B SE2 | MSI Z270M Mortar | GTX 1660 Super | 16GB RAM |
Konsoler: Xbox One X | Xbox 360 | Xbox | PS4 | PS3 | PS2 | Wii

Permalänk
Medlem
Skrivet av Flopper:

23% boost i FC4 fury x
grymt

Var kan man läsa mer om detta?

Permalänk
Medlem

@makarickiri:
Okej tack så mycket. Jag installerade nyss bara för "att" hehe.

Permalänk
Medlem
Skrivet av jonas1972:

Jag antar att du har fel i din signatur då eftersom du verkar ha väntat på drivrutinen:-)

Inte alls fel i sig, men man har fler datorer att ta hand om ibland än ens huvudskrälle.

Visa signatur

The cookie goes *crumble*.

Permalänk
Medlem
Skrivet av Dallebull:

Fanns en ny version av patchern så nu funkar 120hz igen

Kan inte aktivera VSR dock... Lägga till en custom upplösning i CRU hjälper ju inte heller. :/ Använder CRU för att få en 120hz@2560x1440 profil.

Kan vara så att grafikkortet inte orkar skicka ut den signalen som behövs om du inte nu kör via displayport till skärmen.

testat 60 hz med 2560x1440 ?

Visa signatur

Ryzen 5 5600, MSI B450 Tomahawk Max, 2x8 gb kingston reaper 3200 mhz Gigabyte GTX 1660 Super OC och nätagg be quiet 700w SSD: 120 gb pny cs 900, Kingston Fury 1 tb, wd blue ssd 500gb

Permalänk
Inofficiell ambassadör
Skrivet av Fatty:

så är det amd eller asus som bestämmer? Om det är asus och dom väljer att ej ge deras kort möjligheten så är det nog sista gången jag köper asus kort.

Asus har inget med det att göra. De tillverkar bara kylaren och monterar ihop korten.

Skickades från m.sweclockers.com

Visa signatur

Mobo Aorus B550 Pro V2 CPU Ryzen 5600X RAM Corsair Vengance 16GB @ 36000 MHZ
GPU MSI GTX 1080 ti Gaming X Skärm Acer X34A

Permalänk
Medlem

Jag körde den rakt över 15.6 och det funkar bra
Gör så när jag är lat. Blir det inte bra så är det DDU som gäller.

Visa signatur

CPU: I7 7700k @ 4.6GHz - Noctua NH D15S - Asus ROG Strix Z270F Gaming.
GPU: RTX 3070TI @2 st 120mm cf-v12hp hydro dynamic fläktar. 👍
RAM: 32GB DDR4 3200MHz. HÅRDDISK: 4 st SSD, 2 Mekaniska.
MONITOR:1 Xiaomi MI 34"- 3440x1440 144Hz MONITOR:2 Optix MAG274R 27" 1080p 144Hz MONITOR/Tv:3 LG 47lv355n-ZB 47". Nätagg: Corsair Newton R2 1000W. Allt i ett Cooler Master CM Storm Stryker.

Permalänk
Medlem
Skrivet av milo_:

Var kan man läsa mer om detta?

Enda jag hittar är ett forum inlägg http://www.overclock.net/t/1547314/official-amd-r9-radeon-fur...

Permalänk
Medlem
Skrivet av biorrith:

"Uppmärksamma användare har säkert lagt märke till att Radeon 300-serien trots samma grafikprocessorer som 200-serien i många fall har bättre prestanda. Detta tillskrivs att de förbättrade drivrutinerna var låsta till den nygamla serien, någonting som åtgärdats med Catalyst 15.7 WHQL"

Innebär det att 290 får samma prestanda som 390???

Exakt samma får du inte. 390 har högre GPU klock och högre minnes clock.
Men om du sätter samma clocks, så ja, i teorin bör du få samma, då det är samma kort.

290 fick redan en bra boost vid sommaren 2014, och nu en till vid sommaren 2015. Mycket beräkningskraft i ett gammalt kort, och det gör ju att man kanske inte alltid måste uppdatera

Skrivet av Dalton Sleeper:

Hm, 260 och uppåt, någon som vet om dessa nya features fungerar på 7970 eller är dom mjukvarulåsta till 200-serien och upp?

Tekniskt sett kan du köra CF med 280(X) och 7950(70), då de är samma kort (även om de får clock justera). Men om inte AMD lagt in en drivrutinsblock så lär alla funktioner som fungerar på 280 eller 280X fungera på ditt kort också, då det är samma kärna. AMD brukar dock köra med öppna kort och jag har inte sett dem blocka något som fungerar, som tyvärr Nvidia älskar att göra. Sen om AMD har optimerat dem för ditt kort är en annan sak.

Permalänk
Datavetare
Skrivet av philipborg:

Säger inte om det är rätt eller fel val men det är förståeligt att GCN och Dx11 inte spelar så optimalt med varandra medans GCN är grym på Dx12/Vulkan/Mantle. Det har med arkitekturen där GCN är grym på parallellitet, även tidiga GCN versioner. Dx11 var däremot rätt jävla kasst på parallellitet så blev inte en optimal blandning.
Fermi, Kepler och framför allt Tesla var lite motsatta där dem är starkare per tråd men lägre parallellism. Maxwell börjar närma sig en blandning mellan parallellism och Fermi/Kepler strukturen.
Sedan håller jag med om att Nvidia har låg overhead i Dx12, men det är inte i närheten utav GCN. Till och med 285 kan ju göra fler drawcalls än 980, speciellt med 4 kärnor där den leder med 17%. Mycket möjligt däremot att dem siffrorna ändras lite iom fler drivrutiner men GCN älskar verkligen Dx12

Är rätt uppenbart att kostnaden för "draw-calls" knappast kan vara en relevant kostnad i dagens titlar (möjligt att det ändras i framtiden). Läser man AnandTechs test av Fury X så konstaterar man att precis som R9 285 så får man lägre genomsnittlig FPS med Mantle i BF4 och Dragon Age. Det som 285 och Fury X har gemensamt är GCN1.2, kort med GCN1.0/1.1 får något bättre genomsnittlig FPS i dessa titlar med Mantle.

Tyvärr tror jag detta bara är toppen på isberget av problem vi kommer se med DX12. Nackdelen med ett "high-level" API som DX11 och tidigare är att det kan ta lite mer resurser och lägger väldigt stor börda utveckling av drivrutiner för GPU-tillverkarna. Fördelen är att drivar-lagret är ett utmärkt ställe att göra optimeringar, lösa eventuella arkitekturspecifika problem i vissa modeller etc, allt detta ansvar ligger med "låg-nivå" APIer helt i knät på speltillverkarna, att tro det ska bli en förbättring för något annat än de för tillfället absolut mest populära GPU-modellerna lär vara rejält naivt att tro.

Att GCN1.2 presterar sämre med Mantle är sannolikt en effekt av att man använder resurser på ett sätt som råkar trigga någon arkitekturskillnad, något i detta fall verkar leda till en prestandaregression för GCN1.2 GPUer. Med DX11 kan man hantera denna eventuella skillnad i drivern.

Tittar man på resultaten för AMDs nuvarande DX11 drivare så är det största problemet jämför med Nvidia kanske inte absolut overhead, det är att AMD har absolut noll (i vissa fall till och med negativ) skalning med CPU-kärnor. Nvidia har inte i närheten av linjär skalning i DX11, men den är i alla fall positiv!

Enligt Nvidia ser de inte "low-overhead" som den största fördelen med DX12, deras största upplevda problem är att 3D-grafik och specifikt drivare får med DX11 (och tidigare) hantera väldigt mycket data som man vet bara kommer hanteras en gång, något som är väldigt förödande för prestanda av hela applikationen då det orsakar s.k. CPU-cache trashing. Redan 2009 jobbade Nvidia med vad som anses vara lösning på problem, det kallas bindless textures.

DX12 har en generaliserad variant av bindless textures där även en del andra resurser är "bindless". Det jag sett en del klagat på är att DX12 bara borde tagit in "bindless resources" men däremot undvikit "low-overhead" delar som manuell minneshantering och direkt exponering av en del andra finesser (som i praktiken gör det omöjligt att vidareutveckla GPU-designen på sätt som får dess grundläggande design att avvika från DX12 abstraktion av en GPU).

Framtiden lär utvisa om "low-overhead" är en bra idé, men tror tyvärr skeptikerna får rätt här. "low-overhead" är helt vettig för konsoler där det finns en enda HW-konfiguration. Low-level APIer brukar i princip alltid vara en usel idé om variansen på det som ska realisera APIet är stor, man uppfann t.ex. operativsystem just för att programmerare inte ska behöva tänka på HW-specifika detaljer.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av makarickiri:

FRTC fungerade ju sådär för mig :/
Har cap'at fps vid 60 men dom enda programmen som det faktiskt fungerar i är Valley och 3DMARK. Alla spel rullar på som vanligt och ignorerar FRTC -.-

Någon som får det att fungera riktigt?

Det fungerade för mig igår. Det kräver dock att man kör i "Fullscreen" och inte i "Windowed" eller "Windowed borderless fullscreen" för att kicka in.

Visa signatur

Workstation 5950X|7900XTX|O11 Dynamic Vardagsrum 3900X|6900XT|Torrent Nano
VR Reverb G2|PSVR2|Pico 4|Quest 3|Oculus Quest|Samsung Odyssey+

Permalänk
Hjälpsam
Skrivet av Yoshman:

Är rätt uppenbart att kostnaden för "draw-calls" knappast kan vara en relevant kostnad i dagens titlar (möjligt att det ändras i framtiden). Läser man AnandTechs test av Fury X så konstaterar man att precis som R9 285 så får man lägre genomsnittlig FPS med Mantle i BF4 och Dragon Age. Det som 285 och Fury X har gemensamt är GCN1.2, kort med GCN1.0/1.1 får något bättre genomsnittlig FPS i dessa titlar med Mantle.

Tyvärr tror jag detta bara är toppen på isberget av problem vi kommer se med DX12. Nackdelen med ett "high-level" API som DX11 och tidigare är att det kan ta lite mer resurser och lägger väldigt stor börda utveckling av drivrutiner för GPU-tillverkarna. Fördelen är att drivar-lagret är ett utmärkt ställe att göra optimeringar, lösa eventuella arkitekturspecifika problem i vissa modeller etc, allt detta ansvar ligger med "låg-nivå" APIer helt i knät på speltillverkarna, att tro det ska bli en förbättring för något annat än de för tillfället absolut mest populära GPU-modellerna lär vara rejält naivt att tro.

Att GCN1.2 presterar sämre med Mantle är sannolikt en effekt av att man använder resurser på ett sätt som råkar trigga någon arkitekturskillnad, något i detta fall verkar leda till en prestandaregression för GCN1.2 GPUer. Med DX11 kan man hantera denna eventuella skillnad i drivern.

Tittar man på resultaten för AMDs nuvarande DX11 drivare så är det största problemet jämför med Nvidia kanske inte absolut overhead, det är att AMD har absolut noll (i vissa fall till och med negativ) skalning med CPU-kärnor. Nvidia har inte i närheten av linjär skalning i DX11, men den är i alla fall positiv!

Enligt Nvidia ser de inte "low-overhead" som den största fördelen med DX12, deras största upplevda problem är att 3D-grafik och specifikt drivare får med DX11 (och tidigare) hantera väldigt mycket data som man vet bara kommer hanteras en gång, något som är väldigt förödande för prestanda av hela applikationen då det orsakar s.k. CPU-cache trashing. Redan 2009 jobbade Nvidia med vad som anses vara lösning på problem, det kallas bindless textures.

DX12 har en generaliserad variant av bindless textures där även en del andra resurser är "bindless". Det jag sett en del klagat på är att DX12 bara borde tagit in "bindless resources" men däremot undvikit "low-overhead" delar som manuell minneshantering och direkt exponering av en del andra finesser (som i praktiken gör det omöjligt att vidareutveckla GPU-designen på sätt som får dess grundläggande design att avvika från DX12 abstraktion av en GPU).

Framtiden lär utvisa om "low-overhead" är en bra idé, men tror tyvärr skeptikerna får rätt här. "low-overhead" är helt vettig för konsoler där det finns en enda HW-konfiguration. Low-level APIer brukar i princip alltid vara en usel idé om variansen på det som ska realisera APIet är stor, man uppfann t.ex. operativsystem just för att programmerare inte ska behöva tänka på HW-specifika detaljer.

Jag tror att du är lite väl pessimistisk.
Portningen från Konsoler till DX12 kommer bli betydligt enklare än till DX11.
Vad gäller de små utvecklarna kan de använda färdiga spelmotorer.
DX11 finns ju också kvar; om något är för besvärligt att implementera i de hårdvarunära delarna i DX12, kan man ju använda de delar av API:et som har högre abstraktionsnivå.
Många nya delar verkar ju också göra programmeringen enklare inte svårare, tex det virtuella videominnet.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Datavetare
Skrivet av Ratatosk:

Jag tror att du är lite väl pessimistisk.
Portningen från Konsoler till DX12 kommer bli betydligt enklare än till DX11.
Vad gäller de små utvecklarna kan de använda färdiga spelmotorer.
DX11 finns ju också kvar; om något är för besvärligt att implementera i de hårdvarunära delarna i DX12, kan man ju använda de delar av API:et som har högre abstraktionsnivå.
Många nya delar verkar ju också göra programmeringen enklare inte svårare, tex det virtuella videominnet.

Jag hoppas det är väl pessimistisk, tyvärr kan jag inte komma på ett enda exempel där lågnivå API har visat sig vara en bra idé på PC, någon får gärna peka på exempel som visar motsatsen. Däremot finns det flera exempel där det fungerat i inbyggda system, men då har man just samma typ av spikad HW som på konsolerna, d.v.s. väldigt stort antal enheter med exakt samma HW-spec.

Potentiella räddningen i detta fall är just spelmotorerna, det som måste hända är att AMD/Nvidia börjar aktivt jobba på att fixa optimeringen mot deras GPUer direkt i spelmotorerna i stället för att som idag göra det mot drivers. En förutsättning för detta är att det handlar om väldigt få olika spelmotorer alt. man bryter ut någon form av backend/driver som delas av flera spelmotorer.

Virtuella videominnet förenklar bl.a. "bindless resources" om jag förstått rätt, så det är definitivt något bra. Däremot är minneshanteringen i DX12 manuell (d.v.s. ett problem för spelet), vilket betyder att de optimeringar som AMD pratade om i Fury X inte är möjligt i DX12 då det man pratade om här är att det fanns en hel del optimeringar att göra i DX6-DX11 då det är upp till drivaren där att avgöra vad som ligger i VRAM och vad som ligger i system RAM.

Direktportning från konsol är rätt enkelt redan idag. Men är inte gnället från PC-lägret just att man inte vill se direkportar, då utnyttjar man inte alls den extra kraft som typiskt finns i PC-system? Vi har redan sett hur bra det går med "extrafinesser" som HairWorks (bygger på standardfunktion i DX11 som i praktiken är betydligt effektivare på Maxwell än andra kort) och TressFX (som bygger på DirectCompute, fungerar riktigt bra på GCN och Fermi, mindre bra på Kepler/Maxwell).

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem
Skrivet av Yoshman:

Är rätt uppenbart att kostnaden för "draw-calls" knappast kan vara en relevant kostnad i dagens titlar (möjligt att det ändras i framtiden). Läser man AnandTechs test av Fury X så konstaterar man att precis som R9 285 så får man lägre genomsnittlig FPS med Mantle i BF4 och Dragon Age. Det som 285 och Fury X har gemensamt är GCN1.2, kort med GCN1.0/1.1 får något bättre genomsnittlig FPS i dessa titlar med Mantle.

Tyvärr tror jag detta bara är toppen på isberget av problem vi kommer se med DX12. Nackdelen med ett "high-level" API som DX11 och tidigare är att det kan ta lite mer resurser och lägger väldigt stor börda utveckling av drivrutiner för GPU-tillverkarna. Fördelen är att drivar-lagret är ett utmärkt ställe att göra optimeringar, lösa eventuella arkitekturspecifika problem i vissa modeller etc, allt detta ansvar ligger med "låg-nivå" APIer helt i knät på speltillverkarna, att tro det ska bli en förbättring för något annat än de för tillfället absolut mest populära GPU-modellerna lär vara rejält naivt att tro.

Att GCN1.2 presterar sämre med Mantle är sannolikt en effekt av att man använder resurser på ett sätt som råkar trigga någon arkitekturskillnad, något i detta fall verkar leda till en prestandaregression för GCN1.2 GPUer. Med DX11 kan man hantera denna eventuella skillnad i drivern.

Tittar man på resultaten för AMDs nuvarande DX11 drivare så är det största problemet jämför med Nvidia kanske inte absolut overhead, det är att AMD har absolut noll (i vissa fall till och med negativ) skalning med CPU-kärnor. Nvidia har inte i närheten av linjär skalning i DX11, men den är i alla fall positiv!

Enligt Nvidia ser de inte "low-overhead" som den största fördelen med DX12, deras största upplevda problem är att 3D-grafik och specifikt drivare får med DX11 (och tidigare) hantera väldigt mycket data som man vet bara kommer hanteras en gång, något som är väldigt förödande för prestanda av hela applikationen då det orsakar s.k. CPU-cache trashing. Redan 2009 jobbade Nvidia med vad som anses vara lösning på problem, det kallas bindless textures.

DX12 har en generaliserad variant av bindless textures där även en del andra resurser är "bindless". Det jag sett en del klagat på är att DX12 bara borde tagit in "bindless resources" men däremot undvikit "low-overhead" delar som manuell minneshantering och direkt exponering av en del andra finesser (som i praktiken gör det omöjligt att vidareutveckla GPU-designen på sätt som får dess grundläggande design att avvika från DX12 abstraktion av en GPU).

Framtiden lär utvisa om "low-overhead" är en bra idé, men tror tyvärr skeptikerna får rätt här. "low-overhead" är helt vettig för konsoler där det finns en enda HW-konfiguration. Low-level APIer brukar i princip alltid vara en usel idé om variansen på det som ska realisera APIet är stor, man uppfann t.ex. operativsystem just för att programmerare inte ska behöva tänka på HW-specifika detaljer.

Jag håller med allt du säger här Har aldrig sagt att DrawCalls är flaskhalsen i spel, men det är ett någorlunda mått på overhead som diskuterades. (Eller? Jag vet inte hur du annars ska mäta.) Det med AMD's dåliga tråd skalning med Dx11 är intressant och det visste jag inte. Verkar däremot som dem löst det med Dx12 drivrutinerna, ordentliga laster väntar vi på att se. Jag förstår vad du menar med att Dx12 extrema low-level mycket möjligt inte är optimal. Är nog inte tillräckligt kunnig om grafiska API's för att uttala mig allt för mycket. Är däremot inte dem flesta sakerna för Dx12 optionals? Alltså att om en grafikkorts arkitektur deriverar så behöver den bara följa Dx12_0 utan optionals och sedan ha egna optionals utan att förlora spel kompatibilitet? Blir däremot precis som du säger då att det faller till alla utvecklarna att optimera för den deriverande kretsen medans drivrutins tillverkarna får sitta och rulla tummarna lite. (T.ex. Trueaudio även om det inte är grafiskt.)

Är det samma sak som gäller för Vulkan då? Jag är inte allt för insatt i detta som tidigare sagt. Funderar på att lära mig Vulkan när det släpps som mitt första 3D-api. Är inte även Dx11_3 en high level mix utav Dx12 och Dx11?

Generellt om low-level vs high-level så är enligt mig high-level oftast bäst sedan så gör man per arkitektur förbättringar i en kompiler eller liknande. För GPU's blir det i drivrutinerna. Lite som med JRE där man matar en rätt så generell kod men som sedan kan optimeras och fungera för arkitekturen den körs på även om prestandan inte är lika bra som om programmet skrivits speciellt för arkitektur X.

Visa signatur

Citera eller @philipborg om du vill att jag ska läsa dina svar.

Permalänk
Datavetare
Skrivet av philipborg:

Jag håller med allt du säger här Har aldrig sagt att DrawCalls är flaskhalsen i spel, men det är ett någorlunda mått på overhead som diskuterades. (Eller? Jag vet inte hur du annars ska mäta.) Det med AMD's dåliga tråd skalning med Dx11 är intressant och det visste jag inte. Verkar däremot som dem löst det med Dx12 drivrutinerna, ordentliga laster väntar vi på att se. Jag förstår vad du menar med att Dx12 extrema low-level mycket möjligt inte är optimal. Är nog inte tillräckligt kunnig om grafiska API's för att uttala mig allt för mycket. Är däremot inte dem flesta sakerna för Dx12 optionals? Alltså att om en grafikkorts arkitektur deriverar så behöver den bara följa Dx12_0 utan optionals och sedan ha egna optionals utan att förlora spel kompatibilitet? Blir däremot precis som du säger då att det faller till alla utvecklarna att optimera för den deriverande kretsen medans drivrutins tillverkarna får sitta och rulla tummarna lite. (T.ex. Trueaudio även om det inte är grafiskt.)

Är det samma sak som gäller för Vulkan då? Jag är inte allt för insatt i detta som tidigare sagt. Funderar på att lära mig Vulkan när det släpps som mitt första 3D-api. Är inte även Dx11_3 en high level mix utav Dx12 och Dx11?

Generellt om low-level vs high-level så är enligt mig high-level oftast bäst sedan så gör man per arkitektur förbättringar i en kompiler eller liknande. För GPU's blir det i drivrutinerna. Lite som med JRE där man matar en rätt så generell kod men som sedan kan optimeras och fungera för arkitekturen den körs på även om prestandan inte är lika bra som om programmet skrivits speciellt för arkitektur X.

Det är definitivt möjligt att Draw Calls blir en flaskhals i framtida spel, idag har man ju lagt krut i PC-spel just för att komma runt det och vad jag läst har man lite annat angreppssätt kring detta på konsoler. Ett exempel är att open-world spel blir enklare att göra varierade i sin grafik om man kan göra fler Draw Calls, du kan rendera olika träd, byggnader etc medan en typisk PC-optimering är att rendera exakt samma objekt fast väldigt många gånger (kostar då i Draw Calls ungefär som att rendera ett objekt).

Har inte läst in mig tillräckligt på vare sig DX12 eller Vulkan för att exakt förstå vilken typ av abstraktion man valt. Har läst en del kommenterar från folk som tittat på DX12 att abstraktionen man valt "läcker" långt mer information kring hur dagens GPUer fungera jämfört med DX11. Fördelen med DX12 är naturligtvis att det blir väldigt lite "översättningar" (low-overhead), nackdelen är att det bara är sant så länge som gränssnittet mot GPUn ser ut ungefär som den gör idag.

Visa signatur

Care About Your Craft: Why spend your life developing software unless you care about doing it well? - The Pragmatic Programmer

Permalänk
Medlem

En sak jag har märkt med denna updatteringen jämfört med tidigare är att min idle power (har däremot webbläsaren uppe.) har gått ner från ~25w till ~15w för min 295x2 (båda kärnorna sammanlagt.). Det är riktigt trevligt och kan innebära att man kan göra passiv kylning av vissa kort 200 series kort kanske? Någon som är villig att testa? Tror 290/290x tri-x kommer klara det.

EDIT: Var 10W utan webläsare. Däremot stängdes min ena kärna av sig så 10w från ena kärnan och 0 från den andra.

Skrivet av Yoshman:

Det är definitivt möjligt att Draw Calls blir en flaskhals i framtida spel, idag har man ju lagt krut i PC-spel just för att komma runt det och vad jag läst har man lite annat angreppssätt kring detta på konsoler. Ett exempel är att open-world spel blir enklare att göra varierade i sin grafik om man kan göra fler Draw Calls, du kan rendera olika träd, byggnader etc medan en typisk PC-optimering är att rendera exakt samma objekt fast väldigt många gånger (kostar då i Draw Calls ungefär som att rendera ett objekt).

Har inte läst in mig tillräckligt på vare sig DX12 eller Vulkan för att exakt förstå vilken typ av abstraktion man valt. Har läst en del kommenterar från folk som tittat på DX12 att abstraktionen man valt "läcker" långt mer information kring hur dagens GPUer fungera jämfört med DX11. Fördelen med DX12 är naturligtvis att det blir väldigt lite "översättningar" (low-overhead), nackdelen är att det bara är sant så länge som gränssnittet mot GPUn ser ut ungefär som den gör idag.

Kommer oavsett bli intressant att se hur det blir med Dx12/Vulkan. Jag får däremot känslan att Vulkan mycket möjligt kommer "läcka" mindre, men är bara magkänsla. Vulkan är ju trots allt byggt för att vara portabelt precis som OpenGL och känns inte så jätte smart att "läcka" allt för mycket då.

Visa signatur

Citera eller @philipborg om du vill att jag ska läsa dina svar.

Permalänk
Medlem

@mini-z1994:

Den ska ju downsampla allt till 2560x1440 igen så vad DL-DVI kan mata ut ska ju inte spela ngn roll.
Funkar dock inte på mina 1024x1240 sidor skärmar heller så kan vara att jag har 7-serien ( o dessutom kör CFX vilket lär ställa till det ytterligare)
Tvn fungerar det på dock, wierd.

Permalänk
Medlem
Skrivet av Dallebull:

@mini-z1994:

Den ska ju downsampla allt till 2560x1440 igen så vad DL-DVI kan mata ut ska ju inte spela ngn roll.
Funkar dock inte på mina 1024x1240 sidor skärmar heller så kan vara att jag har 7-serien ( o dessutom kör CFX vilket lär ställa till det ytterligare)
Tvn fungerar det på dock, wierd.

För mig funkar det på min 1080p-huvudskärm (digital) men inte på min sekundära skärm, VGA 1280x1024 men den är analog om det spelar någon roll. Tycker inte det borde det, men verkar så.

Skickades från m.sweclockers.com

Visa signatur

Storburk: Ryzen 7 3700X, MSI B450M Mortar, FD Define Mini, CM M2 Silent 720W, 32 GB, ASUS RX 580 8GB, NVME SSD + HDD - HTPC: Ryzen 5 2400G, 16 GB, NVME SSD, BeQuiet 550W - Bärbar: ASUS F3SR, Core2Duo@2,6-3,1Ghz 4 GB, SSD

Permalänk
Medlem
Skrivet av Dallebull:

@mini-z1994:

Den ska ju downsampla allt till 2560x1440 igen så vad DL-DVI kan mata ut ska ju inte spela ngn roll.
Funkar dock inte på mina 1024x1240 sidor skärmar heller så kan vara att jag har 7-serien ( o dessutom kör CFX vilket lär ställa till det ytterligare)
Tvn fungerar det på dock, wierd.

Jag kan aktivera VSR men inte höja upplösningen någonstans. Dota är helt ospelbart nu också. Det verkar finnas en del konstigheter med 15.7 tyvärr.

Jag har gått tillbaka till 15.6 då den fungerar mycket bättre för mig.

Permalänk
Medlem
Skrivet av WEKS:

Tack. Hittade samma inlägg igår kväll. Vet inte hur jag ska tolka det eftersom att SweC fick nästan exakt samma resultat med 15.15 som användaren fick med 15.7. Kan mycket väl vara en förbättring eftersom att vi inte vet användarens resterande komponenter.