AMD Polaris & Vega og midlertidig (?) Navi

[Malvado]

 

Er vel kanskje ikke så langt fra sannheten...

Polaris 10 blir en Hawaii-erstatter. Polaris 11 blir en low-end brikke for å erstatte 370 og lavere.

...

Her kommer det blant annet frem at Polaris har samme "gfx IP" som Tonga og Fiji. Det kan type på at det primært er 14nm prosessen som er nytt i de første Polaris-brikkene, og at flere av GCN Gen4 endringene først kommer med Vega (tidligere Greenland) i 2017.

Da viser deg seg at informasjonen jeg hadde i mars og de videre antakelsene mine stemte godt...

 

ISA (instruksjonsettet) på GCN4 som "Polaris" er bygget på er identisk med ISA for GCN3 (Fiji, Tonga). Det vil si at optimeringen AMD har gjort primært er på backend-nivået i brikken. Det betyr også at Polairs kun støtter DirectX 12 feature level 12_0, og at AMD enda ikke har implementert støtte for conservative rasterization og Rasterizer Ordered Views (ROV) også kjent som feature level 12_1.

Forhåpentligvis kommer dette på Vega i 2017...

 

 

Denne er fortsatt relevant i denne sammenhengen : http://www.extremetech.com/extreme/207598-demystifying-directx-12-support-what-amd-intel-and-nvidia-do-and-dont-deliver

 

Nå kommer det heller ikke som en overraskelse at GCN arkitekturen baserer seg på tidligere Gpu'er hos Amd men man har fått på plass en god del forbedringer.

 

På samme måte kan man jo si at Nvidia mangler konkrete ting i 10xx serien som Amd har å plass og man kan jo håpe at Nvidia får disse på plass.

 

https://techaltar.com/amd-improving-gcn-shader-intrinsic-functions/

[HKS]

Nå kommer det heller ikke som en overraskelse at GCN arkitekturen baserer seg på tidligere Gpu'er hos Amd men man har fått på plass en god del forbedringer.

Jeg synes at det er litt overraskende at AMD som liker å skryte av at de er best på DX12 ikke har implementert feature level 12_1. Både Nvidia (Maxwell Gen2 & Pascal) og Intel (Skylake) har klart dette.

 

På samme måte kan man jo si at Nvidia mangler konkrete ting i 10xx serien som Amd har å plass og man kan jo håpe at Nvidia får disse på plass.

Hva er det du mener Nvidia mangler i 10xx serien? Endret 5. juli 2016 av HKS

[Malvado]

 

Nå kommer det heller ikke som en overraskelse at GCN arkitekturen baserer seg på tidligere Gpu'er hos Amd men man har fått på plass en god del forbedringer.

Jeg synes at det er litt overraskende at AMD som liker å skryte av at de er best på DX12 ikke har implementert feature level 12_1. Både Nvidia (Maxwell Gen2 & Pascal) og Intel (Skylake) har klart dette.

 

På samme måte kan man jo si at Nvidia mangler konkrete ting i 10xx serien som Amd har å plass og man kan jo håpe at Nvidia får disse på plass.

Hva er det du mener Nvidia mangler i 10xx serien?

 

 

Nvidia sin implementering av Async Compute er på ingen måte lik Amd sin implementering 

 

 

Even with all of these additions, Pascal still won’t quite match GCN. GCN is able to run async compute at the SM/CU level, meaning each SM/CU can work on both graphics and compute at the same time, allowing even better efficiency. Nonetheless, Pascal is finally offering a solution with hardware scheduled async compute, bringing Nvidia closer to AMD. Either way, with both Nvidia and AMD working on async compute, developers are more likely to take notice and make sure our GPUs are fully utilized.

 

Så kan man jo se på implementeringen i noen spill som nå er til salgs som for eksempel Hitman 2016 og Ashes og Tomb Raider , og der ser man jo at det er forskjeller på hvordan skjermkortene jobber. Enten har Nvidia sinnsykt mye å gjøre med driverne sine og man vil gradvis se ytelsen øke, kanskje til og med dramtisk , eller så er det rett og slett hvordan mange av de nye funksjonene er implementert i Hardware og software som gjør at ytelsen i mange tilfeller faller såpass lavt.

 

Det er forskjell på hvor mye av DX 12 som støttes både hos Amd og Nvidia , per dags dato har jeg ikke hørt ( men kom gjerne med inside info om du kan) at Nvidia eller Amd engang er i nærheten av full DX12 støtte.

[HKS]

 

 

Nå kommer det heller ikke som en overraskelse at GCN arkitekturen baserer seg på tidligere Gpu'er hos Amd men man har fått på plass en god del forbedringer.

Jeg synes at det er litt overraskende at AMD som liker å skryte av at de er best på DX12 ikke har implementert feature level 12_1. Både Nvidia (Maxwell Gen2 & Pascal) og Intel (Skylake) har klart dette.

 

På samme måte kan man jo si at Nvidia mangler konkrete ting i 10xx serien som Amd har å plass og man kan jo håpe at Nvidia får disse på plass.

Hva er det du mener Nvidia mangler i 10xx serien?

 

 

Nvidia sin implementering av Async Compute er på ingen måte lik Amd sin implementering 

Even with all of these additions, Pascal still won’t quite match GCN. GCN is able to run async compute at the SM/CU level, meaning each SM/CU can work on both graphics and compute at the same time, allowing even better efficiency. Nonetheless, Pascal is finally offering a solution with hardware scheduled async compute, bringing Nvidia closer to AMD. Either way, with both Nvidia and AMD working on async compute, developers are more likely to take notice and make sure our GPUs are fully utilized.[/size]

 

Så kan man jo se på implementeringen i noen spill som nå er til salgs som for eksempel Hitman 2016 og Ashes og Tomb Raider , og der ser man jo at det er forskjeller på hvordan skjermkortene jobber. Enten har Nvidia sinnsykt mye å gjøre med driverne sine og man vil gradvis se ytelsen øke, kanskje til og med dramtisk , eller så er det rett og slett hvordan mange av de nye funksjonene er implementert i Hardware og software som gjør at ytelsen i mange tilfeller faller såpass lavt.

 

Det er forskjell på hvor mye av DX 12 som støttes både hos Amd og Nvidia , per dags dato har jeg ikke hørt ( men kom gjerne med inside info om du kan) at Nvidia eller Amd engang er i nærheten av full DX12 støtte.

 

For det første er ikke "Async Compute" en del av noe DirectX 12 feature level.

 

For det andre så er det enda ingen av spillene som har optimert eller blitt patchet med hensyn på støtten som er i Pascal. Det er dessverre ikke bare "Plug & Play" her, og mye kan ikke gjøres fra driver. Det er dessverre en av utfordringene vi kommer til å få med slike lavnivå API.

 

Den enste "gode" testen av Async Compute er foreløpig et testprogram som en bruker på "Beyond3D" har laget. Denne viser at Pascal overlapper grafikk og compute veldig bra.

 

Det er også viktig og ikke se seg blind på hvor mange prosent bedre ytelsen blir av å slå på en optimering som Async Compute. Async Compute handler om å overlappe grafikk og beregninger på GPU, da er du avhengig at det faktisk kan overlappes. Det er også viktig å se på sluttresultatet som er om man kan makse alle effektene og få en så god som mulig frame rate.

 

Det har også vært en tendens til at man ser seg blind på hvor stor ytelsesforbedring AMD har fra DX11 til DX12. Det er ikke bare en effekt av at AMD har en "god" DX12 arkitektur, men også en effekt av at AMD i mange tilfeller har en mye dårligere optimert DX11 driver enn Nvidia.

[Sparrk]

kjøpte meg akkurat et Sapphire RX480 fra CDON. Leste akkruat at de forventer om ikke lenge at Sapphire NITRO med bedre kjølere og OC fra fabrikk lanseres snart. Noen som har anelse om når dette kommer? og hvilken pris vi kan forvente?

[Malvado]

For det første er ikke "Async Compute" en del av noe DirectX 12 feature level.

 

For det andre så er det enda ingen av spillene som har optimert eller blitt patchet med hensyn på støtten som er i Pascal. Det er dessverre ikke bare "Plug & Play" her, og mye kan ikke gjøres fra driver. Det er dessverre en av utfordringene vi kommer til å få med slike lavnivå API.

 

Den enste "gode" testen av Async Compute er foreløpig et testprogram som en bruker på "Beyond3D" har laget. Denne viser at Pascal overlapper grafikk og compute veldig bra.

 

Det er også viktig og ikke se seg blind på hvor mange prosent bedre ytelsen blir av å slå på en optimering som Async Compute. Async Compute handler om å overlappe grafikk og beregninger på GPU, da er du avhengig at det faktisk kan overlappes. Det er også viktig å se på sluttresultatet som er om man kan makse alle effektene og få en så god som mulig frame rate.

 

Det har også vært en tendens til at man ser seg blind på hvor stor ytelsesforbedring AMD har fra DX11 til DX12. Det er ikke bare en effekt av at AMD har en "god" DX12 arkitektur, men også en effekt av at AMD i mange tilfeller har en mye dårligere optimert DX11 driver enn Nvidia.

 

 

Da får du nesten ta opp dette med Asyncrounous compute enten med Microsoft og DX12 , media som stadig vekk påpeker at "Nå har Nvidia fått DX12 oppdateringen med Async Compute , eller fra Nvidia sin egen inforbok om Compute Engine innenfor Cuda " .

 

Man kan jo selvsagt gå denne veien via Microsoft sin informasjon om DX12 : Multi-Engine and Multi-Adapter Synchronization > Synchronization and Multi-Engine > Asynchronous compute and graphics example :

 

 

 

Asynchronous compute and graphics example

This next example allows graphics to render asynchronously from the compute queue. There is still a fixed amount of buffered data between the two stages, however now graphics work proceeds independently and uses the most up-to-date result of the compute stage as known on the CPU when the graphics work is queued. This would be useful if the graphics work was being updated by another source, for example user input. There must be multiple command lists to allow theComputeGraphicsLatency frames of graphics work to be in flight at a time, and the function UpdateGraphicsCommandList represents updating the command list to include the most recent input data and read from the compute data from the appropriate buffer.

The compute queue must still wait for the graphics queue to finish with the pipe buffers, but a third fence (pGraphicsComputeFence) is introduced so that the progress of graphics reading compute work versus graphics progress in general can be tracked. This reflects the fact that now consecutive graphics frames could read from the same compute result or could skip a compute result. A more efficient but slightly more complicated design would use just the single graphics fence and store a mapping to the compute frames used by each graphics frame.

 

 

void AsyncPipelinedComputeGraphics()

{

const UINT CpuLatency = 3;

const UINT ComputeGraphicsLatency = 2;

 

// Compute is 0, graphics is 1

ID3D12Fence *rgpFences[] = { pComputeFence, pGraphicsFence };

HANDLE handles[2];

handles[0] = CreateEvent(nullptr, FALSE, TRUE, nullptr);

handles[1] = CreateEvent(nullptr, FALSE, TRUE, nullptr);

UINT FrameNumbers[] = { 0, 0 };

 

ID3D12GraphicsCommandList *rgpGraphicsCommandLists[CpuLatency];

CreateGraphicsCommandLists(ARRAYSIZE(rgpGraphicsCommandLists),

rgpGraphicsCommandLists);

 

// Graphics needs to wait for the first compute frame to complete, this is the

// only wait that the graphics queue will perform.

pGraphicsQueue->Wait(pComputeFence, 1);

 

while (1)

{

for (auto i = 0; i < 2; ++i)

{

if (FrameNumbers > CpuLatency)

{

rgpFences->SetEventOnFenceCompletion(

FrameNumbers - CpuLatency,

handles);

}

else

{

SetEvent(handles);

}

}

 

auto WaitResult = WaitForMultipleObjects(2, handles, FALSE, INFINITE);

auto Stage = WaitResult = WAIT_OBJECT_0;

++FrameNumbers[stage];

 

switch (Stage)

{

case 0:

{

if (FrameNumbers[stage] > ComputeGraphicsLatency)

{

pComputeQueue->Wait(pGraphicsComputeFence,

FrameNumbers[stage] - ComputeGraphicsLatency);

}

pComputeQueue->ExecuteCommandLists(1, &pComputeCommandList);

pComputeQueue->Signal(pComputeFence, FrameNumbers[stage]);

break;

}

case 1:

{

// Recall that the GPU queue started with a wait for pComputeFence, 1

UINT64 CompletedComputeFrames = min(1,

pComputeFence->GetCurrentFenceValue());

UINT64 PipeBufferIndex =

(CompletedComputeFrames - 1) % ComputeGraphicsLatency;

UINT64 CommandListIndex = (FrameNumbers[stage] - 1) % CpuLatency;

// Update graphics command list based on CPU input and using the appropriate

// buffer index for data produced by compute.

UpdateGraphicsCommandList(PipeBufferIndex,

rgpGraphicsCommandLists[CommandListIndex]);

 

// Signal *before* new rendering to indicate what compute work

// the graphics queue is DONE with

pGraphicsQueue->Signal(pGraphicsComputeFence, CompletedComputeFrames - 1);

pGraphicsQueue->ExecuteCommandLists(1,

rgpGraphicsCommandLists + PipeBufferIndex);

pGraphicsQueue->Signal(pGraphicsFence, FrameNumbers[stage]);

break;

}

}

}

}

 

Endret 5. juli 2016 av Malvado

[HKS]

Da får du nesten ta opp dette med Asyncrounous compute enten med Microsoft og DX12 , media som stadig vekk påpeker at "Nå har Nvidia fått DX12 oppdateringen med Async Compute , eller fra Nvidia sin egen inforbok om Compute Engine innenfor Cuda " .

 

Man kan jo selvsagt gå denne veien via Microsoft sin informasjon om DX12 : Multi-Engine and Multi-Adapter Synchronization > Synchronization and Multi-Engine > Asynchronous compute and graphics example :

 

Asynchronous compute and graphics example

This next example allows graphics to render asynchronously from the compute queue. There is still a fixed amount of buffered data between the two stages, however now graphics work proceeds independently and uses the most up-to-date result of the compute stage as known on the CPU when the graphics work is queued. This would be useful if the graphics work was being updated by another source, for example user input. There must be multiple command lists to allow theComputeGraphicsLatency frames of graphics work to be in flight at a time, and the function UpdateGraphicsCommandList represents updating the command list to include the most recent input data and read from the compute data from the appropriate buffer.

The compute queue must still wait for the graphics queue to finish with the pipe buffers, but a third fence (pGraphicsComputeFence) is introduced so that the progress of graphics reading compute work versus graphics progress in general can be tracked. This reflects the fact that now consecutive graphics frames could read from the same compute result or could skip a compute result. A more efficient but slightly more complicated design would use just the single graphics fence and store a mapping to the compute frames used by each graphics frame.

 

Det eneste du viser er et eksempel på hvordan du kan overlappe grafikk og compute. DirectX 12 skal eksponere to forskjellige køer. Flere køer, en for grafikk, minst en for compute og en for overføringer mellom CPU og GPU.

 

DirectX spesifikasjonen sier ingenting om hvordan grafikkdriveren skal eksekvere dette. Det kan både gjøres asynkront som er den mest optimale måten, såfremt du har ledige ressurser, eller den kan gjøres serielt. Det vil si etter hverandre.

 

Forskjellen her mellom DX11 og DX12 er at i DX11 så kjører du bare alle jobbene inn i en kø.

 

 

Når jeg snakker om feature levels i DirectX så refererer det til minimumskrav til hvilke operasjoner på grafikksiden som en GPU må støtte.

 

[ExcaliBuR]

For det andre så er det enda ingen av spillene som har optimert eller blitt patchet med hensyn på støtten som er i Pascal. Det er dessverre ikke bare "Plug & Play" her, og mye kan ikke gjøres fra driver. Det er dessverre en av utfordringene vi kommer til å få med slike lavnivå API.

 

Var det ikke nVidia som skulle "fikse" Async med driveroppdatering til forrige gen.(Maxwell?)?

[Nizzen]

Hvis bf1 alpha varer over neste helg, så skal jeg teste titan x vs 1080 i dx 12. Nå i ferien er det 980ti jeg bruker hos lillebror. Bf1 går bra i dx12 med 980ti. Retail bf1 blir nok referanse spill i dx12 fremover

[Malvado]

Kan vel nevne at Tomshardware har kommet til sin konlusjon når det gjelder strømforbruket via pci-e til  RX 480 kortene :

http://www.tomshardware.com/reviews/amd-radeon-rx-480-power-measurements,4622-2.html

 

 

The AMD Radeon RX 480’s power supply configuration exceeds the limit defined by the PCI-SIG’s specifications. It doesn’t exceed them by a massive amount, but it does do so reliably. Norms should be respected, especially if they already have a very generous built-in tolerance range. We never implied in our launch article that a system made up of solid components might be directly damaged by an AMD Radeon RX 480 graphics card running at stock clock frequencies.

There shouldn’t be any problems unless cheap, dirty or outdated components are used, the card isn’t installed correctly, or the amount of power drawn is increased by overclocking the card.

[-=HellBound=-]

Ja blir spennende å se, test gjerne dx11 vs dx12 om det går. Frostbite motoren funker veldig bra på alt av hardware så det er nå hvert fall veldig bra. Det spillet kommer garantert med som bundle av amd skjermkort siden de har vist det frem på så og si på alle events. Litt artig at du kan få "Awarded to players who make the best choices with AMD Radeon" under Exclusives Dog Tags =p 

[HKS]

 

For det andre så er det enda ingen av spillene som har optimert eller blitt patchet med hensyn på støtten som er i Pascal. Det er dessverre ikke bare "Plug & Play" her, og mye kan ikke gjøres fra driver. Det er dessverre en av utfordringene vi kommer til å få med slike lavnivå API.

 

Var det ikke nVidia som skulle "fikse" Async med driveroppdatering til forrige gen.(Maxwell?)?

 

Det må også støttes fra applikasjonen. 

 

Nvidia har slått på støtte i Maxwell Gen2 nå, men det er som nevnt tidligere begrenset. GPU må statisk partisjoneres. GPU må også vente til inneværende jobb (f. eks draw call) er ferdig før du kan endre partisjonen. Da blir det fort mye resurser idle. Det kan gå greit med lette workloads, men ved tunge workloads er det problematisk. Det må uansett tunes for i applikasjonen, og er høyst sannsynlig ikke verdt innsatsen.

 

Pascal fikser disse begrensningene, den kan dynamisk repartisjonere distribusjonen mellom compute og grafikk. I tillegg kan du gjøre fingranulær preemption, du kan avbryte og bytte ut oppgaver som kjører på instruksjon eller pixel granularitet.

 

Noe annen AMD har hatt støtte for lenge, men Nvidia nå også støtter er høy-prioritet køer på Pascal og Maxwell (Maxwell har som nevnt tidligere her også begrensninger, men støtter det). Dette vil åpne opp for å avlaste mer spilllogikk til GPU, noe som vil kunne være nyttig i fremtiden.

[Malvado]

 

We promised an update today (July 5, 2016) following concerns around the Radeon™ RX 480 drawing excess current from the PCIe bus. Although we are confident that the levels of reported power draws by the Radeon RX 480 do not pose a risk of damage to motherboards or other PC components based on expected usage, we are serious about addressing this topic and allaying outstanding concerns. Towards that end, we assembled a worldwide team this past weekend to investigate and developa driver update to improve the power draw. We’re pleased to report that this driver—Radeon Software 16.7.1—is now undergoing final testing and will be released to the public in the next 48 hours.

In this driver we’ve implemented a change to address power distribution on the Radeon RX 480 – this change will lower current drawn from the PCIe bus.

Separately, we’ve also included an option to reduce total power with minimal performance impact. Users will find this as the “compatibility” UI toggle in the Global Settings menu of Radeon Settings. This toggle is “off” by default.

Finally, we’ve implemented a collection of performance improvements for the Polaris architecture that yield performance uplifts in popular game titles of up to 3%. These optimizations are designed to improve the performance of the Radeon RX 480, and should substantially offset the performance impact for users who choose to activate the “compatibility” toggle.

AMD is committed to delivering high quality and high performance products, and we’ll continue to provide users with more control over their product’s performance and efficiency. We appreciate all the feedback so far, and we’ll continue to bring further performance and performance/W optimizations to the Radeon RX 480.

 

Amd kom med uttalelser om problemet i går : https://www.facebook.com/AMDGaming/?fref=nf

[Tåkefyrste]

Er grunnen til at nVidia generelt er så mye raskere i DX11 at den har overlegen Pixel fillrate, eller er det mer avansert enn som så?

AMD har jo bedre specs på så og si alt annet om man sammenligner kort i samme prisklasse, men selv blir de knust.

[Malvado]

Er litt hvordan arkitekturen fungerer om jeg forstår det rett.

Ser man også på ytelsen over tid så har faktisk 2xx serien gått gradvis opp i ytelse , sammenligner man med noen tester kan dette være relativt mye , jeg hadde (mener jeg) rundt 40 - 45 ish fps i Thief spillet med de første driverne , nå ligger jeg som regel på omtrent 55 - 60 ish eller høyere med nyere drivere.

 

Men på DX12 så har det ikke vært så veldig stor forskjell , noe som tyder på at driverne der greier å utnytte skjermkortene bedre , nå kan jeg ikke sammenligne så mye med GCN 4 som RX 480 har, men igjen så ser jeg på mitt 280 at noe forbedring har det vært der også men ikke like mye som på DX11.

 

Men igjen kanskje ikke så rart da jeg tipper at både eldre GCN og andre faktorer spiller inn her da jeg ser at nyere kort også der har litt mer å gå på.

 

Man må jo også huske på at AMD har en veldig strerk konkurrent i Nvidia og at de feilstegene Amd har gjort over tid har virkelig kostet , noe man igjen ser på produktene som blir levert. RX 480 burde ha hatt noe høyere hastighet fra dag 1 og noe lavere strømforbruk , årsaken til at dette ikke var tilfelle blir å spekulere, men kan være pga valg av arkitektur eller Ingeniørene til AMD.

[Gralle]

Sikkert en grunn (som feil på noe i GPU) til at de er merket 4GB istedenfor 8GB, men vert en forsøk for de som føler seg klar for det. Husk bare at det ikke er sikkert at det går bra og du må flashe tilbake. Eget ansvar etc.

 

AMD Radeon RX 400 news: Polaris BIOS editor, Sapphire RX 400 series

http://videocardz.com/61897/amd-radeon-rx-400-news-polaris-bios-editor-sapphire-rx-400-series

 

AMD RX 480 4GB Cards Are Rebadged 8GB 480s, Unlocked With A BIOS Flash – Full Step By Step Guide

http://wccftech.com/amd-rx-480-4gb-retail-cards-8gb/#ixzz4Dhphp24f

Endret 7. juli 2016 av Gralle

[Nizzen]

Radeon Software Crimson Edition is AMD's revolutionary new graphics software that delivers redesigned functionality, supercharged graphics performance, remarkable new features, and innovation that redefines the overall user experience. Every Radeon Software release strives to deliver new features, better performance and stability improvements.
Radeon Software Crimson Edition 16.7.1 Highlights

The Radeon™ RX 480’s power distribution has been improved for AMD reference boards, lowering the current drawn from the PCIe bus.
A new “compatibility mode” UI toggle has been made available in the Global Settings menu of Radeon Settings. This option is designed to reduce total power with minimal performance impact if end users experience any further issues. This toggle is “off” by default.
Performance improvements for the Polaris architecture that yield performance uplifts in popular game titles of up to 3% [1]. These optimizations are designed to improve the performance of the Radeon™ RX 480, and should substantially offset the performance impact for users who choose to activate the "compatibility" toggle.

Fixed Issues
Radeon™ RX 480 limited PCI-E Bandwidth (PCI-E bandwidth is now at the correct speed on the Radeon™ RX 480) with Radeon Software Crimson Edition 16.7.1.
Minor stuttering no longer occurs in Grand Theft Auto V on Radeon™ RX 480 with Radeon Software Crimson Edition 16.7.1.
Video corruption will not be observed in DOOM with resolutions above 1920x1080 with Radeon Software Crimson Edition 16.7.1.
Hitman™ graphical corruption no longer occurs when the game is set to use DirectX®12 API and using zoom with weapons with Radeon Software Crimson Edition 16.7.1.
Display will not exhibit minor flicker on Radeon™ RX 480 when Freesync is enabled on a games launch or exit with Radeon Software Crimson Edition 16.7.1.

Known Issues
A few game titles may fail to launch or crash if the AMD Gaming Evolved overlay is enabled. A temporary workaround is to disable the AMD Gaming Evolved "In Game Overlay".
Radeon™ Pro Duo may experience a black screen in Total War™: Warhammer with the games API set to DirectX®12 and V-Sync enabled.
DiRT™ Rally may experience flickering terrain in some races when the advanced blending option is enabled in the games settings page.
Some Overdrive settings may not appear in Radeon Settings for Radeon™ Fury X when in AMD Crossfire mode.
Dota™2 may crash when using the Vulkan™ API and the user changes resolutions or quality settings.
Battlefield™ 4 may experience crashes when using Mantle. As a work around users are suggested to switch to DirectX®11.
Need for Speed™ may experience flickering on some light sources in AMD Crossfire mode.
Frame Rate Target Control gaming profiles may fail to enable for some games.
Radeon Wattman may retain settings of an overclock after it has failed. If you have failed an overclock with a system hang or reboot make sure to use the "Reset" option in the Radeon WattMan settings page when the system has rebooted.
Low frame rate or stutter may be experienced Wolfenstein®: The Old Blood™ on Radeon™ RX 480.
Assassin's Creed® Syndicate may experience a game crash or hang when in game settings are set to high or greater.
Disabling AMD Crossfire mode on Radeon™ RX 480 may disable the device in Windows® Device Manager. A workaround is to reboot the system to re-enable the device.

Source

Hotlink gikk visst ikkje

Endret 7. juli 2016 av Nizzen

[Tåkefyrste]

Thanks, får vel installere da, for å være på den sikre siden.

[Gjest bruker-293283]

http://www.pcper.com/reviews/Graphics-Cards/AMD-Radeon-RX-480-Power-Consumption-Concerns-Fixed-1671-Driver

Ser ut til at den nye driveren reduserer trekket fra PCIe slotten med ca 10Watt og øker tilsvarende fra 6pins kontakten.

Endret 7. juli 2016 av bruker-293283

[-=HellBound=-]

Da var det fikset ja. http://www.tomshardware.com/reviews/amd-radeon-rx-480-polaris-power-fix,4668.html?_ga=1.182928164.364014649.1467457783