CJ's Radeon Info & Nieuwsdiscussie - Deel 126

[Cheezus]

checkout10 schreef op donderdag 02 januari 2014 @ 14:16:
[afbeelding]
Wat een groot verschil is dat! Bron
Edit: de kaart in het rood is zo te zien revisie 1.

Of er is gewoon iets mis met die test. Als je de rest van de resultaten bekijkt zijn de verschillen helemaal niet zo groot en zit de gigabyte een beetje in het midden qua prestaties.

[DCG909]

Ik denk idd dat het eerder iets is met de test (of dat de kaart defect is geraakt oid?)
De verschillen zijn gewoon te groot...

[Toettoetdaan]

Bron: http://udteam.tistory.com/594

[Astennu]

Toettoetdaan schreef op maandag 06 januari 2014 @ 11:53:
[afbeelding]
Bron: http://udteam.tistory.com/594

Ik had het een paar dagen terug ook al gelezen. Zou grappig zijn als het echt zo is en er ook nog een fully unlocked versie komt. Al schijnt er in dat soort chips altijd wat redundant spul in te zitten om de yields hoog te houden. Wellicht had Tahiti er ook meer dan 2048.

[Help!!!!]

AMD Demonstrates "FreeSync", Free G-Sync Alternative, at CES 2014

Hopelijk wordt dit op korte termijn wat. "Freesync", klinkt goed toch?

[Toettoetdaan]

Help!!!! schreef op dinsdag 07 januari 2014 @ 04:36:
AMD Demonstrates "FreeSync", Free G-Sync Alternative, at CES 2014

Hopelijk wordt dit op korte termijn wat. "Freesync", klinkt goed toch?

Nice, ook gewoon geen extra hardware nodig en de huidige generatie ondersteund het al.
Dat doen ze gewoon heel goed

[AMD_Aero]

CES: AMD: "Battlefield 4 met Mantle tot 45% sneller"

Hardware.info heeft nieuws over Mante
45% mag er wel wezen en zorgt er zeker voor dat de A10 reeks meer en meer interessant wordt voor budget gaming systemen.

[Anoniem: 64183]

Waarschijnlijk gemeten met een multi-GPU opstelling met een wat zwakkere CPU. Misschien niet de zwaarste setting om de CPUs nog wat invloed te laten hebben. Maar desondanks...zelfs in dit scenario is dit wel een groot verschil.

[Toettoetdaan]

[Lambo LP670 SV]

Anoniem: 64183 schreef op dinsdag 07 januari 2014 @ 10:51:
Waarschijnlijk gemeten met een multi-GPU opstelling met een wat zwakkere CPU. Misschien niet de zwaarste setting om de CPUs nog wat invloed te laten hebben. Maar desondanks...zelfs in dit scenario is dit wel een groot verschil.

Is gemeten met een A10-7850K in combinatie met 1 R9 290X

[BramT]

Erg leuk, dat FreeSync. Kon een gniffel niet onderdrukken. Maar nu de hamvraag: hoe/waar kunnen we vinden of onze monitortjes hier ondersteuning voor hebben?
Ik heb al even gezocht maar fabrikanten maken inderdaad nergens melding van VESA VBLANK ondersteuning e.d.

[TNJ]

Zal ook een pricewatch optie nodig hebben, als de producenten met de info komen. Een soort van "Variabele framerate: Nee/G-Sync/Freesync"

[Werelds]

BramT schreef op dinsdag 07 januari 2014 @ 14:33:
Erg leuk, dat FreeSync. Kon een gniffel niet onderdrukken. Maar nu de hamvraag: hoe/waar kunnen we vinden of onze monitortjes hier ondersteuning voor hebben?
Ik heb al even gezocht maar fabrikanten maken inderdaad nergens melding van VESA VBLANK ondersteuning e.d.

Het zit in de DisplayPort standaard; de framing symbols is waar het om draait. Wordt ook al gebruikt voor PSR (Panel Self Refresh) om stroom te besparen.

Ik heb even een mail naar Eizo geschoten om te kijken of zij wat duidelijkheid kunnen verschaffen (en of hun FG2421 dit bijvoorbeeld wellicht al kan)

[tobitronics]

BramT schreef op dinsdag 07 januari 2014 @ 14:33:
Erg leuk, dat FreeSync. Kon een gniffel niet onderdrukken. Maar nu de hamvraag: hoe/waar kunnen we vinden of onze monitortjes hier ondersteuning voor hebben?
Ik heb al even gezocht maar fabrikanten maken inderdaad nergens melding van VESA VBLANK ondersteuning e.d.

He bah, heb net 2 Dell Ultrasharp monitoren sinds een maand staan. Of zou freesync gewoon op elke monitor kunnen werken?

[BramT]

Hier iemand die het allemaal netjes uitlegt:

It seems that some people don't understand what is going on, so I'm going to try and clear some things up.
VBLANK (or Vertical Blanking Interval) is not anything new. It refers to something that was necessary for CRT monitors to function, and has hung around in current monitor technology for backwards compatibility sake.
G-Sync, in fact, manipulates the VBLANK variable to do 90% of what it does, as explained in this review's how does it work section. It does so by the installation of a controller chip that allows the VBLANK variable to be controlled by the graphics card.

What AMD has done is develop their own implementation of this for a demo by taking advantage of some displays that allow for this VESA defined variable to be manipulated by software. However, the VESA standard that this comes from VESA Coordinated Video Timings standard (VESA-2003-9) does not define an API to manipulate this variable. The choice of exposing this variable externally is up to the display manufactures, as many manufactures are going to leave it locked to the native refresh frequency. Many laptop manufactures will implement control of it on their display for power management purposes (which makes sense), and AMD was able to develop and demo using one of those displays.

AMD is attempting to create a more cost effective solution that puts makes this purely a display manufacture support issue. They are attempting to shift the onus of this issue and prevent NVIDIA from having a meaningful product differentiation technology. If display manufactures agree, then they will have succeeded.
However, just like NVIDIA, they are at the mercy of display manufactures adopting their method. Given that the ball is already rolling (to a degree) for G-Sync adoption, they may be late to the party.


Dus... het is maar de vraag (zelfs erg twijfelachtig) of je huidige monitor dit gaat ondersteunen. In theorie zou het mogelijk moeten zijn met een firmware update van je monitor, maar aangezien dit zo goed als nooit voorkomt voor main-steam monitoren hoeven we daar niet op te wachten.

[ Voor 86% gewijzigd door BramT op 07-01-2014 18:47 . Reden: Mijn gebrabbel vervangen door iemand die het netjes kan uitleggen :) ]

[Phuncz]

De eerste fabrikant met een 30" IPS monitor met FreeSync support heeft mij als klant. G-Sync is leuk maar typisch Nvidia: vendor lockin, serieus bijbetalen en geen garantie dat je er volgend jaar nog veel aan hebt met een nieuwe, incompatibele versie of staking door fabrikanten, evenals de zeer beperkte keuze in de afzienbare tijd.

In dat opzicht is FreeSync the way to go. Als zelfs simpele schermen een sRGB voorziening hebben, dan moet het men ook wel lukken om een extra selling point te maken door FreeSync-compatible te zijn.

[ Voor 4% gewijzigd door Phuncz op 07-01-2014 19:26 ]

[enchion]

Ik denk zelf dat de schermfabrikanten uiteindelijk liever vanuit een open standaard zelf iets in hun scaler implementeren om de communicatie met de GPU tot stand te brengen dan proprietary spul van Nvidia er in te gaan bouwen.

Want zoals het gesteld is is het is alleen maar dat de ene tegen de ander vertelt wanneer hij klaar is wat geen erg grote overbrugging moet zijn.

Kans op patent problemen mbt Nvidia (als er toch een alternatieve chip oplossing komt) is ook klein aangezien Nvidia gewoon een vrije standaard misbruikt.

Daarbuiten is het gewoon zo dat Gsync geen enkele waarde heeft als je je spel speelt met meer FPS dan je scherm aan kan.
(aangezien 60FPS voor mij inmiddels een absoluut minimum is (op mijn 60hz scherm) voor bijna alle spellen, wordt ik er dus ook absoluut niet warm van.)

Lijkt mij dus dat Gsync een stille dood zal gaan sterven en misschien alleen overblijft voor klanten die zo graag een groen logo`tje willen hebben.

[Help!!!!]

Nog wat Freesync items:

AMD could counter Nvidia's G-Sync with simpler, free sync tech

AMD's under reported dynamic refresh rates

The exec's puzzlement over Nvidia's use of external hardware was resolved when I spoke with him again later in the day. His new theory is that the display controller in Nvidia's current GPUs simply can't support variable refresh intervals, hence the need for an external G-Sync unit. That would explain things. I haven't yet had time to confirm this detail with Nvidia or to quiz them about whether G-Sync essentially does triple-buffering in the module. Nvidia has so far been deliberately vague about certain specifics of how G-Sync works, so we'll need to pry a little in order to better understand the situation.

Regardless, the good news here is that AMD believes a very effective G-Sync-like variable refresh technology shouldn't add any cost at all to a display or system. The term "free sync" is already being spoken as shorthand for this technology at AMD.

That said, AMD is still in the early stages of cooking up a potential product or feature along these lines, and it has nothing official to announce just yet.

AMD believes the primary constraint in making this capability widespread is still monitor support. Although adding dynamic refresh to a monitor may cost next to nothing, monitor makers have shown they won't bother unless they believe there's some obvious demand for that feature. PC enthusiasts and gamers who want to see "free sync" happen should make dynamic refresh support a requirement for their next monitor purchase. If monitor makers get the message, then it seems likely AMD will do its part to make dynamic display synchronization a no-cost-added feature for Radeon owners everywhere.

[BramT]

[b][message=41550846,noline]...
Daarbuiten is het gewoon zo dat Gsync geen enkele waarde heeft als je je spel speelt met meer FPS dan je scherm aan kan.
...

Da's natuurlijk niet helemaal waar. Gsync (/Freesync) zorgen er in zo'n geval voor dat je game op de max frequentie van je monitor draait, en dat is nogal altijd beter dan VSYNC op 60hz of helemaal geen sync.

(Of ondersteunen spellen ook VSYNC op 120/144hz? Geen idee eigenlijk.... Als dat zo is dan ja, dan heeft het geen meerwaarde )

[Tijgert]

Veel higher end (hogere resolutie) monitoren halen geen veel hogere refresh rate dan 80Hz en daarboven kom je tegen de limiet van je videoverbindign aan. Dus Gsync die je mooi op 120/144Hz wilt laten lopen zal nooit werken. Niet iedereen draait op 1080p 120Hz monitoren...

[Help!!!!]

http://www.techpowerup.co...-sync-gaming-monitor.html

Deze komt begin Q2 op de markt en daar gaat Gsync prima mee werken. Sowieso fijn dat er eindelijk schot lijkt te komen in 27" WQHD (2560 x 1440) monitoren met 120+ Hz.

Alleen heb ik liever het Freesync (mooie naam ook ) alternatief (ervanuitgaande dat nvidia daar ook mee overweg kan tzt.)

[Astennu]

Maar nVidia zit daar niet op te wachten. Nu kunnen zij extra geld verdienen met die Controller boards die in de monitoren moeten.

Net als met de SLI licentie voor moederborden waar je bij AMD gewoon op ieder moederbord met 2 sloten Crossfire mag doen moet je bij nVidia betalen voor een Licentie moet aanwezig zijn in de bios anders werkt het niet.

[Help!!!!]

Astennu schreef op woensdag 08 januari 2014 @ 10:53:
Maar nVidia zit daar niet op te wachten. Nu kunnen zij extra geld verdienen met die Controller boards die in de monitoren moeten.

Net als met de SLI licentie voor moederborden waar je bij AMD gewoon op ieder moederbord met 2 sloten Crossfire mag doen moet je bij nVidia betalen voor een Licentie moet aanwezig zijn in de bios anders werkt het niet.

Klopt maar er is natuurlijk ook wel wat te zeggen voor het feit dat je wilt verdienen aan tech waar je in geinvesteerd hebt. Het zal interessant zijn om te zien of monitor fabrikanten hun tech willen aanpassen of dat ze liever via het nvidia model extra geld proberen te verdienen door alleen g sync te promoten.

Interessant stukje met nvidia's response hieronder. Eerste user reactie daaronder is ook interessant:

http://techreport.com/new...nds-to-amd-free-sync-demo

Nvidia responds to AMD's ''free sync'' demo

by Scott Wasson — 2:57 AM on January 8, 2014

CES — On the show floor here at CES today, I spoke briefly with Nvidia's Tom Petersen, the executive instrumental in the development of G-Sync technology, about the AMD "free sync" demo we reported on yesterday. Alongside the demo, a senior AMD engineering executive asserted that a variable refresh rate capability like G-Sync ought to be possible essentially for free, without adding any extra costs to a display or a PC system. Peterson had several things to say in response to AMD's demo and claims.

He first said, of course, that he was excited to see his competitor taking an interest in dynamic refresh rates and thinking that the technology could offer benefits for gamers. In his view, AMD interest was validation of Nvidia's work in this area.

However, Petersen quickly pointed out an important detail about AMD's "free sync" demo: it was conducted on laptop systems. Laptops, he explained, have a different display architecture than desktops, with a more direct interface between the GPU and the LCD panel, generally based on standards like LVDS or eDP (embedded DisplayPort). Desktop monitors use other interfaces, like HDMI and DisplayPort, and typically have a scaler chip situated in the path between the GPU and the panel. As a result, a feature like variable refresh is nearly impossible to implement on a desktop monitor as things now stand.

That, Petersen explained, is why Nvidia decided to create its G-Sync module, which replaces the scaler ASIC with logic of Nvidia's own creation. To his knowledge, no scaler ASIC with variable refresh capability exists—and if it did, he said, "we would know." Nvidia's intent in building the G-Sync module was to enable this capability and thus to nudge the industry in the right direction.

When asked about a potential VESA standard to enable dynamic refresh rates, Petersen had something very interesting to say: he doesn't think it's necessary, because DisplayPort already supports "everything required" for dynamic refresh rates via the extension of the vblank interval. That's why, he noted, G-Sync works with existing cables without the need for any new standards. Nvidia sees no need and has no plans to approach VESA about a new standard for G-Sync-style functionality—because it already exists.

That said, Nvidia won't enable G-Sync for competing graphics chips because it has invested real time and effort in building a good solution and doesn't intend to "do the work for everyone." If the competition wants to have a similar feature in its products, Petersen said, "They have to do the work. They have to hire the guys to figure it out."

This sentiment is a familiar one coming from Nvidia. The company tends to view its GeForce GPUs and related solutions as a platform, much like the Xbox One or PS4. Although Nvidia participates in the larger PC gaming ecosystem, it has long been guarded about letting its competitors reap the benefits of its work in various areas, from GPU computing to PhysX to software enablement of advanced rendering techniques in AAA games.

Like it or not, there is a certain competitive wisdom in not handing off the fruits of your work to your competition free of charge. That's not, however, how big PC players like Intel and AMD have traditionally handled new standards like USB and x86-64. (Intel in particular has done a lot of work "for everyone.")

If you recall our report from yesterday on this subject, Nvidia and AMD do seem to agree on some of the key issues here. Both firms have told us that the technology to support variable refresh rates exists in some cases already. Both have said that the biggest challenge to widespread adoption of the tech on the desktop is support among panel (and scaler ASIC) makers. They tend to disagree on the best means of pushing variable refresh tech into wider adoption. Obviously, after looking at the landscape, Nvidia chose to build the G-Sync module and enable the feature itself.

My sense is that AMD will likely work with the existing scaler ASIC makers and monitor makers, attempting to persuade them to support dynamic refresh rates in their hardware. Now that Nvidia has made a splash with G-Sync, AMD could find this path easier simply because monitor makers may be more willing to add a feature with obvious consumer appeal. We'll have to see how long it takes for "free sync" solutions to come to market. We've seen a number of G-Sync-compatible monitors announced here at CES, and most of them are expected to hit store shelves in the second quarter of 2014.

cygnus1
Jan 805:24 AM
+-+1
Let me see if I get what's happened here. VESA was doing their thing a few years ago and created a free, better version of HDMI, aka displayport. Laptop people said, 'sweet, a free display interface, let's get that extended a bit for our use'. eDP is born, Wikipedia: DisplayPort, and it includes the power saving feature for "seamless refresh rate switching". AMD and nVidia support it in silicon because it's in the standard and they're unifying their mobile and desktop silicon. Normal desktop monitors don't support it since it's an embedded interface, so nobody notices for years.

VESA keeps doing their thing with regular old displayport, keeps making it better, starts planning v1.3 a while ago and which is now due out this year. nVidia sees this coming, since they're a member of VESA. Somebody at nVidia decides, let's pitch this old idea that's about to come to desktops anyway as our own before everybody else supports it because it's the freaking standard. Also, rebrand it so it looks like nVidia came up with it too. (copied that play from Apple I think)

Basically all nVidia has done is produce the silicon for a monitor to support a feature of displayport 1.3 before it's a ratified standard and before anybody else. Or hell maybe gsync is just eDP, who knows since nVidia doesn't talk about their 'secret sauce' like AMD does when the secret sauce is really an open standard.

I will bet that in less than 18 months crap loads of monitors will support this.

[madmaxnl]

Astennu schreef op woensdag 08 januari 2014 @ 10:53:
Maar nVidia zit daar niet op te wachten. Nu kunnen zij extra geld verdienen met die Controller boards die in de monitoren moeten.

Net als met de SLI licentie voor moederborden waar je bij AMD gewoon op ieder moederbord met 2 sloten Crossfire mag doen moet je bij nVidia betalen voor een Licentie moet aanwezig zijn in de bios anders werkt het niet.

Dat kan nooit om veel geld gaan, dat SLI gebeuren dan he. Immers zouden fabrikanten dan toch twee identieke moederborden uitbrengen met verschillende firmware waarbij de non-SLI versie weer een paar dollar goedkoper is.

[Astennu]

madmaxnl schreef op woensdag 08 januari 2014 @ 13:09:
[...]


Dat kan nooit om veel geld gaan, dat SLI gebeuren dan he. Immers zouden fabrikanten dan toch twee identieke moederborden uitbrengen met verschillende firmware waarbij de non-SLI versie weer een paar dollar goedkoper is.

Klopt. En dat gebeurd ook. Het gaat ook maar om een paar dollar 5-10 of zo. Maar toch. Er worden in totaal aardig wat SLI borden verkocht. En het kost nVdia niets om dit op deze manier te doen ze verdienen er wel dik op.

[Zanac-ex]

Astennu schreef op woensdag 08 januari 2014 @ 13:19:
[...]


Klopt. En dat gebeurd ook. Het gaat ook maar om een paar dollar 5-10 of zo. Maar toch. Er worden in totaal aardig wat SLI borden verkocht. En het kost nVdia niets om dit op deze manier te doen ze verdienen er wel dik op.

Mede door de SLI Certificatie had Nvidia hun zaakjes wel veel eerder in orde dan ATI/AMD.
We weten nog steeds niet exact hoe Nvdia's Frame Pacing oplossing werkt maar dikke kans dat dit mede in de SLI Firmware op het bord zit.

Maak je dit openbaar dat kan de concurentie in de keuken kijken en het groene team staat er om bekend dat ze niet scheutig zijn met het uitdelen van recepten.

[Astennu]

Zanac-ex schreef op woensdag 08 januari 2014 @ 13:48:
[...]


Mede door de SLI Certificatie had Nvidia hun zaakjes wel veel eerder in orde dan ATI/AMD.
We weten nog steeds niet exact hoe Nvdia's Frame Pacing oplossing werkt maar dikke kans dat dit mede in de SLI Firmware op het bord zit.

Maak je dit openbaar dat kan de concurentie in de keuken kijken en het groene team staat er om bekend dat ze niet scheutig zijn met het uitdelen van recepten.

Nee dat heeft er zo ver ik weet helemaal niets mee te maken. Die Licentie is niets meer dan een Key. Is die niet aanwezig schakelt de driver de optie voor SLI uit. Technisch gezien heb je dat helemaal niet nodig en zou SLI ook gewoon op non SLI borden kunnen werken. Dit is opzettelijk geblokkeerd.

Dat Frane Pacing van nVidia heeft daar niets meer te maken. nVidia heeft daar een of andere hardware oplossing voor ingebakken in hun GPU's.

AMD heeft dit niet. Met de R9 290(X) hebben ze wel extra hardware voor de crossfire communicatie over de PCI-E bus. En die gebruikt AMD weer om Frame Pacing te doen. Dit werkt anders dan de oplossing van nVidia. Maar is wel effectief. AL zijn de latency's bij nVidia wat lager.
AMD heeft hierdoor geen CF bridges meer nodig. Maar ik vind die Bridges persoonlijk geen groot nadeel. Zonder is natuurlijk wel makkelijker.

[Zanac-ex]

Astennu schreef op woensdag 08 januari 2014 @ 13:53:
[...]


Nee dat heeft er zo ver ik weet helemaal niets mee te maken. Die Licentie is niets meer dan een Key. Is die niet aanwezig schakelt de driver de optie voor SLI uit. Technisch gezien heb je dat helemaal niet nodig en zou SLI ook gewoon op non SLI borden kunnen werken. Dit is opzettelijk geblokkeerd.

Dat Frane Pacing van nVidia heeft daar niets meer te maken. nVidia heeft daar een of andere hardware oplossing voor ingebakken in hun GPU's.

AMD heeft dit niet. Met de R9 290(X) hebben ze wel extra hardware voor de crossfire communicatie over de PCI-E bus. En die gebruikt AMD weer om Frame Pacing te doen. Dit werkt anders dan de oplossing van nVidia. Maar is wel effectief. AL zijn de latency's bij nVidia wat lager.
AMD heeft hierdoor geen CF bridges meer nodig. Maar ik vind die Bridges persoonlijk geen groot nadeel. Zonder is natuurlijk wel makkelijker.

Ik geloof je!

Ben eigenlijk wel heel benieuwd hoe een R9 290(x) in CF op een PCI-E 16*/4* configuratie presteert, niet dat je dit wilt met High-End GPU's maar uiteindelijk zal deze oplossing ook naar Mid- en Low End kaarten doorstromen.

[Astennu]

Misschien dat techpowerup of HardOCP of zo dit getest heeft.

[haarbal]

Dat "freesync" lijkt min of meer hetzelfde te doen, maar de gebruikte hardware is voor 60 hz max, waar het identiek wordt aan 60 Hz met vsync, is mooi vloeiend, maar de input lag is vervelend (op mijn monitor iig)

Met gsync lijkt 144 Hz op 1920x1080 en 120 Hz op 2560x1440 de norm te worden, waarmee je een hoop vertraging elimineert. ~8ms op de transmissie, ~8ms op de panel refresh, ze vervangen de scaler, dus misschien winnen ze daar ook wat (door sneller of uberhaupt niet te scalen).

Waarschijnlijk speelt een afgekapte 72 (of 48) fps op een 144 Hz monitor, prerendered frames op laagst, met vsync aan ook perfect, zolang je maar nooit dropt, maar ik heb zo'n monitor niet, dus kan ik dat niet testen.

De scaler (voorlopig) vervangen door een dure fpga was blijkbaar de makkelijkste optie om op highend monitoren een variabele framerate te realiseren.

[Phuncz]

haarbal schreef op woensdag 08 januari 2014 @ 16:09:
Dat "freesync" lijkt min of meer hetzelfde te doen, maar de gebruikte hardware is voor 60 hz max, waar het identiek wordt aan 60 Hz met vsync, is mooi vloeiend, maar de input lag is vervelend (op mijn monitor iig)

Het lijkt me dat Free-Sync of G-Sync niet inherent wel of niet verbonden zijn aan de refresh rate van een paneel, het lijkt me dat voor beide het mogelijk is om 120Hz of 60Hz schermen te maken.

In ieder geval verplicht de Free-Sync standaard me niet om nooit verder dan één GPU fabrikant te kijken door opzettelijke vendor lockin. Dat je bij beide een nieuw scherm moet kopen lijkt me logisch, je maakt een LCD scherm ook niet ineens 3D (niet de groen/rood brol) met een softwareupdate. Maar de DP-standaard is door iedereen te gebruiken en AMD geeft de FreeSync standaard ook vrij zover ik begrijp (en het is toch opgenomen in de VESA standaard).

[Toettoetdaan]

haarbal schreef op woensdag 08 januari 2014 @ 16:09:

Je haalt echt een paar dingen door elkaar.

[haarbal]

Phuncz schreef op woensdag 08 januari 2014 @ 16:27:
[...]

Het lijkt me dat Free-Sync of G-Sync niet inherent wel of niet verbonden zijn aan de refresh rate van een paneel, het lijkt me dat voor beide het mogelijk is om 120Hz of 60Hz schermen te maken.

In ieder geval verplicht de Free-Sync standaard me niet om nooit verder dan één GPU fabrikant te kijken door opzettelijke vendor lockin. Dat je bij beide een nieuw scherm moet kopen lijkt me logisch, je maakt een LCD scherm ook niet ineens 3D (niet de groen/rood brol) met een softwareupdate. Maar de DP-standaard is door iedereen te gebruiken en AMD geeft de FreeSync standaard ook vrij zover ik begrijp (en het is toch opgenomen in de VESA standaard).

Maar de bestaande tech is voor 60 Hz en lager. Als 120 Hz zo makkelijk was waren die monitoren niet minstens 2x zo duur. Ook is er geen freesync standaard om door amd te worden vrijgegeven, er is ook niets aangekondigd, alleen dat amd een goedkoper open alternatief leuk zou vinden.
Gsync is idd enorm inefficient qua kosten, aangezien het een dure oplossing is voor een probleem dat er uberhaupt niet had hoeven zijn als hdmi en dvi anders was opgezet, de vendor lock in is ook vervelend, maar het is een werkende oplossing, en is over 4 a 6 maanden te koop.

Toettoetdaan schreef op woensdag 08 januari 2014 @ 16:34:
[...]

Je haalt echt een paar dingen door elkaar, maar ik zeg lekker niet wat.

[Help!!!!]

Stukje van developer Oxide Games over Mantle

YouTube: How AMD's Mantle Tech Makes Games Better

[Sp3ci3s8472]

Help!!!! schreef op woensdag 08 januari 2014 @ 22:30:
Stukje van developer Oxide Games over Mantle

YouTube: How AMD's Mantle Tech Makes Games Better

Voor vermaak lees de comments .

Ze laten hier niet echt meer zien dan dat ze tijdens die presentatie lieten zien jammergenoeg.

[madmaxnl]

Help!!!! schreef op woensdag 08 januari 2014 @ 22:30:
Stukje van developer Oxide Games over Mantle

YouTube: How AMD's Mantle Tech Makes Games Better

2 maanden, één man, één engine (waarschijnlijk wel geen super uitgebreiden engine, maar toch).

[Astennu]

haarbal schreef op woensdag 08 januari 2014 @ 18:52:
[...]


Maar de bestaande tech is voor 60 Hz en lager. Als 120 Hz zo makkelijk was waren die monitoren niet minstens 2x zo duur. Ook is er geen freesync standaard om door amd te worden vrijgegeven, er is ook niets aangekondigd, alleen dat amd een goedkoper open alternatief leuk zou vinden.
Gsync is idd enorm inefficient qua kosten, aangezien het een dure oplossing is voor een probleem dat er uberhaupt niet had hoeven zijn als hdmi en dvi anders was opgezet, de vendor lock in is ook vervelend, maar het is een werkende oplossing, en is over 4 a 6 maanden te koop.


[...]

GSync en Free Sync doen gewoon wat eDP doet (DP 1.3a standaard). Alleen heeft nVidia er hardware tussen gezet wat het nu al mogelijk maakt. Maar het zit gewoon in de DP standaard.

En op laptops werd het al om andere redenen gebruikt. En daar speelt AMD op in om die aansturing over te nemen en dat de matchen met de framerate die de kaart draait.

[ Voor 8% gewijzigd door Astennu op 09-01-2014 10:27 ]

[Toettoetdaan]

haarbal schreef op woensdag 08 januari 2014 @ 18:52:
[...]

Ik zeg 'lekker' niets omdat het onbegonnen werk lijkt, je roept dat de 'bestaande techniek' gelimiteerd is tot 60Hz, wat niet zo is, de bestaande techniek schaalt gewoon mee tot de limiet van de data rate over de display kabel. Ook nVidia heeft aangegeven dat 144Hz de limiet van het paneel was en niet van de G-sync module.
Vervolgens haal je aan dat die 60Hz met vsync zorgt voor vervelende input lag op jouw monitor, terwijl dat juist weer niet bij je monitor ligt, maar bij de vsync techniek op zichzelf.

Daarna maak je nog een rare koppeling tussen G-sync en 144Hz/120Hz, terwijl G-sync waarschijnlijk schaalt van 0Hz tot de limiet van bandbreedte in Hz, G-sync word echter gekoppeld aan game monitoren en de huidige game monitoren zijn 120Hz+. Maar dat maakt nog steeds geen verschil tussen G-sync en FreeSync.

Dat maakt het al dat als ik het lees, ik een gevoel krijg van: 'laat maar', wat je echt probeert te zeggen met je post komt niet uit de verf en dat is jammer van jouw tijd en een beetje jammer van de tijd van iedereen die het gaat proberen uit te leggen.

OT: Hoe snel zou DP1.3a de deur uit kunnen? Ik heb al ergens gelezen dat het accepteren van de standaard 30-90 dagen kost, dan moeten fabrikanten het nog implementeren of een firmware update uitbrengen, dus al met al denk ik dat we over 4 maanden de eerste desktop schermen zien met FreeSync

[Werelds]

haarbal schreef op woensdag 08 januari 2014 @ 18:52:
Maar de bestaande tech is voor 60 Hz en lager. Als 120 Hz zo makkelijk was waren die monitoren niet minstens 2x zo duur. Ook is er geen freesync standaard om door amd te worden vrijgegeven, er is ook niets aangekondigd, alleen dat amd een goedkoper open alternatief leuk zou vinden.

Waar haal jij dit in gods naam vandaan?

Maximale refresh rate is iets dat aan het panel ligt, niet aan de display controller. Je zou G-Sync wel in een 60 Hz TN monitor kunnen stoppen, wordt hij niet magisch 120/144 van. Die refresh rates op die paar G-Sync modellen die zijn aangekondigd zouden niet anders zijn zonder G-Sync. Dat is even afgezien van het feit dat zowel G-Sync als AMD's FreeSync in feite helemaal geen refresh rate hebben.

De enige reden dat AMD's demo 60 Hz was, is omdat dat display een laptop display was dat niet verder dan 60 ging.

Panel Self Refresh (PSR) in eDP 1.3 rept ook met geen woord over een maximum. Nogmaals, dat hangt van het panel af - niet het onderdeel waar Nvidia invloed op uit oefent (hoewel ik me wel kan voorstellen dat ze hebben afgesproken dat dat de norm is). PSR is waarschijnlijk wat AMD gebruikte voor hun demo; dat is een bestaande standaard voor laptop displays. Hoe AMD het toe past is niet de oorspronkelijke toepassing, maar wel correct volgens de spec (zie verder hieronder).

G-Sync doet hoogst waarschijnlijk nagenoeg hetzelfde als AMD heeft laten zien. Zij vereisen ook dat er DisplayPort wordt gebruikt en daar zit het grote punt. DP staat extra signalen toe, dus de G-Sync controller accepteert daar gewoon een direct signaal om een refresh plaats te laten vinden en tot die tijd houdt hij gewoon het laatste frame (zelf) vast. Dat is exact what PSR is.

Nvidia's G-Sync module is niet alleen vervelend vanwege de vendor lock-in, het betekent ook dat je het nooit in een fatsoenlijke monitor zult zien. Dell, Eizo, LG zullen er niet aan beginnen omdat Nvidia's controller hun eigen PCB vervangt. Dan raken ze al hun IP kwijt. Met andere woorden, niet alleen krijgen we dus alleen maar monitors van matige fabrikanten, ze zullen ook allemaal dezelfde beperkingen hebben. Sterker nog, als er hetzelfde paneel wordt gebruikt door twee fabrikanten zal dat er ook echt hetzelfde uit zien omdat de controller er achter hetzelfde is. Ik weet ook wat de module zelfs in bulk buiten het retail kanaal nog kost en laten we het er maar op houden dat de extra centen die je neerlegt voor de G-Sync versie van de VG248QE die kosten niet dekt. Nvidia vraagt echt een belachelijke prijs voor het ding, wat het alleen interessant maakt voor fabrikanten zoals ASUS die zelf die technologie niet in huis hebben. Ik vrees dus dat we G-Sync vooral op stront TN panelen zullen blijven zien. Dat alleen al maakt het voor mij een no-go, laat staan de vendor lock-in.

PSR (en daarmee DP1.3/AMD's demo) daarentegen is veel leuker. Voor diegenen die niet weten hoe het werkt: de GPU mag de display controller in feite opdracht geven om het laatste frame vast te houden tot nader order. Als de GPU dan een nieuw frame klaar heeft, geeft deze dat door aan de display controller en begint meteen het nieuwe frame te versturen. De controller op zijn beurt begint meteen deze nieuwe gegevens te lezen van de input stream. Daarnaast moet hij z'n ververs timing bijstellen om gelijk te lopen met de GPU. Dat laatste is waar het om draait; het betekent dat de rollen omgedraaid worden, waar normaal de GPU wacht op het display, moet met gebruik van PSR juist op de GPU gewacht worden. Hoewel we met Free-/G-Sync uiteraard helemaal geen vaste refresh rate willen, is dit wel de grote clou. Zo kun je een refresh rate van 30 Hz aangeven en na elk frame PSR activeren. Dan krijg je minstens elke 33.33ms een refresh (omdat dat gezonder is voor het panel) - of wanneer de GPU een nieuw frame klaar heeft krijg je dat "meteen" (response time blijft een factor natuurlijk, net als bij G-Sync), en dan op z'n laatst 33.33ms daarna weer. Enige vereiste qua hardware is wat geheugen op de controller om het laatste frame vast te houden. Ook dat is wederom iets wat een off-the-shelf fabrikant zoals ASUS niet heeft, maar Dell/Eizo/LG wel, omdat zij sowieso al wat dingen met elk frame doen.


@ Toettoetdaan: ik zou er niet van staan te kijken als Dell op CEBIT al DP1.3 monitors laat zien. Eizo is hier in elk geval volop mee bezig (ook met FreeSync).

[ Voor 4% gewijzigd door Werelds op 09-01-2014 12:36 ]

[Astennu]

Dell en Eizo gebruiken inderdaad geavanceerde controllers in de duurdere modellen. Daar zitten ook scalars enz in.

[oeLangOetan]

Astennu schreef op donderdag 09 januari 2014 @ 12:43:
Dell en Eizo gebruiken inderdaad geavanceerde controllers in de duurdere modellen. Daar zitten ook scalars enz in.

Ontwikkelen ze die zelf? Indien niet moeten ze gewoon veranderen naar nVidia als leverancier van de scalar; dan gaat het enkel nog over kostprijs & features.

[Help!!!!]

^^^
Ben nogal achterdochtig waar het nvidia betreft en het zou me niks verbazen als het inderdaad zo gegaan is als beschreven in de comment van mijn laatste post hierboven inzake free/g sync.

Laten we in vredesnaam hopen dat Eizo/Dell etc inderdaad snel met monitors komen waarin hetzelfde effect bereikt wordt (via DP1.3 ?etc). Zit zo niet te wachten op Gsync vendor lock in.....

Mijn wensenlijstje ziet er zo uit:

• 27/28 inch
• 2560 x 1440
• 120/144hz
• "Free" sync
• 1ms
• evt. IPS

[Astennu]

Ik wil wel een 30" 4K HD met Freesync

Ik zag dat dell nu met een betaalbare 28" 4K gaat komen voor 700 dollar. Het begint de goede kant op te gaan.

[Help!!!!]

Astennu schreef op donderdag 09 januari 2014 @ 13:11:
Ik wil wel een 30" 4K HD met Freesync

Ik zag dat dell nu met een betaalbare 28" 4K gaat komen voor 700 dollar. Het begint de goede kant op te gaan.

Heb ik ook gezien maar ik ga bewust niet voor UHD omdat ik het liefst speel met hoogst mogelijke IQ en tegelijkertijd ruim boven 60fps uit wil komen.

Maar wellicht krijg ik met freesync wel dezelfde vloeiendheid met 60fps als nu met 100fps en is het dan wel haalbaar...

Daarnaast houd ik het nog wel een jaartje uit. Tegen die tijd is er denk ik behoorlijk wat UHD / freesync aanbod....

[ Voor 12% gewijzigd door Help!!!! op 09-01-2014 13:30 ]

[Astennu]

Tja met UHD kun je AA uit laten bespaart weer wat. En beeld is dan beter dan met een lagere reso en AA. Dat is vooral de rede dat ik naar UHD wil. Gewoon een stukje scherpte er bij. Het is wel veel zwaarder maar je krijgt er ook wat voor terug. En sommige detail settings hakken wel flink in de FPS zonder dat je er veel van ziet. Dus voor mij hoeft niet alles vol uit. Als het qua FPS kan doe ik het wel maar bepaalde dingen zoals SSOA zet ik regelmatig uit.

En met een mooie R9 290X2 kaart er in kun je wel een eindje komen. Ben benieuwd of en wanneer ze uit komen. En of het gerucht van die 30xx shaders waar is. alle shaders aan op lagere clocks is best een manier om de prestaties op te krikken zonder het verbruik extreem omhoog te pushen. Gewoon op 900 MHz clocken met een lager voltage en dan kun je wel binnen het TDP van de 7990 blijven.

[ Voor 54% gewijzigd door Astennu op 09-01-2014 14:36 ]

[haarbal]

Met de speciale module met een hoop memory had ik eigenlijk wel verwacht dat bij gsync de panel refresh los staat van de frames die naar de monitor verzonden worden. Maar goed, misschien is het ook wel alleen een hack om hoogfrequent panel self refresh met de huidige gpu lijn te kunnen doen.

waarom moet een panel eigenlijk elke 1/30 seconde ververst worden werelds? vroeg me af waarom gsync een 30fps ondergrens heeft.

[Astennu]

haarbal schreef op donderdag 09 januari 2014 @ 15:06:
Met de speciale module met een hoop memory had ik eigenlijk wel verwacht dat bij gsync de panel refresh los staat van de frames die naar de monitor verzonden worden. Maar goed, misschien is het ook wel alleen een hack om hoogfrequent panel self refresh met de huidige gpu lijn te kunnen doen.

waarom moet een panel eigenlijk elke 1/30 seconde ververst worden werelds? vroeg me af waarom gsync een 30fps ondergrens heeft.

Het kan aan mij liggen en het is ook niet lullig bedoelt maar volgens mij moet je even wat artikelen gaan lezen over hoe alles werkt zonder GSync en daar na een artiekel (BV op anandtech) over wat GSync nu pressies doet. Want als ik jou reacties lees krijg ik het idee dat je niet snapt hoe het een en ander werkt.

[Werelds]

oeLangOetan schreef op donderdag 09 januari 2014 @ 13:07:
Ontwikkelen ze die zelf? Indien niet moeten ze gewoon veranderen naar nVidia als leverancier van de scalar; dan gaat het enkel nog over kostprijs & features.

In het geval van de fatsoenlijke fabrikanten wel ja (sorry, ik heb geen hoge pet op van Asus/Acer/Viewsonic/etc. met hun 99.9999% TN and 0.0001% ongecalibreerde IPS schermen ). Eizo en Dell hebben beide al geheugen op hun controller PCBs zitten voor de betere monitors. LG durf ik zo niet te zeggen, wel weet ik dat ook zij hun eigen controllers hebben.

haarbal schreef op donderdag 09 januari 2014 @ 15:06:
Met de speciale module met een hoop memory had ik eigenlijk wel verwacht dat bij gsync de panel refresh los staat van de frames die naar de monitor verzonden worden. Maar goed, misschien is het ook wel alleen een hack om hoogfrequent panel self refresh met de huidige gpu lijn te kunnen doen.

waarom moet een panel eigenlijk elke 1/30 seconde ververst worden werelds? vroeg me af waarom gsync een 30fps ondergrens heeft.

Bij deze "variabele refresh rate" (we moeten een term verzinnen heren, Variable VBLANK? Wordt dan VV afgekort ) wordt de refresh uitgevoerd zodra er een frame beschikbaar is, dat is juist het hele punt. Normaal gesproken krijg je de frames alleen op elke "tick" van de display klok; dus elke 1/60e of 1/120e of 1/144e seconde. Is een frame bijvoorbeeld net na tick 30 klaar op 60 Hz (30 * 16.67 = 500.1ms, dus frame bijvoorbeeld klaar op 501ms) krijg je die pas op tick 31 te zien (31 * 16.67 = 516.77ms) met V-Sync - dat is dus bijna 16ms vertraging *bovenop* de tijd die het panel nodig heeft om het nieuwe frame weer te geven. En zonder V-Sync krijg je tearing, dus het frame van tick 29 deels met het nieuwe frame.

Die ondergrens is omdat een LCD panel niet te lang "stil" mag staan. Het is een beetje ingewikkeld om uit te leggen, maar heel in het kort vinden die kristallen dat niet leuk (als je een beetje affiniteit met natuur- en scheikunde hebt is het wel leuk om te lezen ). Eigenlijk een beetje net als een batterij; ook daar blijven de chemicaliën liever in beweging, dus constant laden of ontladen.

[Toettoetdaan]

haarbal schreef op donderdag 09 januari 2014 @ 15:06:
Waarom moet een panel eigenlijk elke 1/30 seconde ververst worden werelds? vroeg me af waarom gsync een 30fps ondergrens heeft.

Wat Werelds zegt en onder de 30Hz zou ik geen vsync meer gebruiken, dan ben je blij met elke stukje frame dat op je scherm komt

Het hele 60hz(/50Hz) gebeuren is eigenlijk een erfenis van vroeger, het 130volt spanningsnet is 60Hz, en in b.v. Nederland is het spanningsnet 230volt/50Hz. Daar borduren we nog steeds een beetje op verder

[Astennu]

Toettoetdaan schreef op donderdag 09 januari 2014 @ 16:24:
[...]

Wat Werelds zegt en onder de 30Hz zou ik geen vsync meer gebruiken, dan ben je blij met elke stukje frame dat op je scherm komt

Het hele 60hz(/50Hz) gebeuren is eigenlijk een erfenis van vroeger, het 130volt spanningsnet is 60Hz, en in b.v. Nederland is het spanningsnet 230volt/50Hz. Daar borduren we nog steeds een beetje op verder

Inderdaad. Gelukkig is het niet meer nodig om je aan die waardes te houden. Echter gaat het nog niet hard qua schermen met meer dan 60 Hz. Ik denk dat dat ook komt omdat de gaming markt en de mensen die perse meer dan 60 Hz willen gewoon (nog) een te kleine markt is.

[haarbal]

Werelds schreef op donderdag 09 januari 2014 @ 16:09:
Bij deze "variabele refresh rate" (we moeten een term verzinnen heren, Variable VBLANK? Wordt dan VV afgekort ) wordt de refresh uitgevoerd zodra er een frame beschikbaar is, dat is juist het hele punt. Normaal gesproken krijg je de frames alleen op elke "tick" van de display klok; dus elke 1/60e of 1/120e of 1/144e seconde. Is een frame bijvoorbeeld net na tick 30 klaar op 60 Hz (30 * 16.67 = 500.1ms, dus frame bijvoorbeeld klaar op 501ms) krijg je die pas op tick 31 te zien (31 * 16.67 = 516.77ms) met V-Sync - dat is dus bijna 16ms vertraging *bovenop* de tijd die het panel nodig heeft om het nieuwe frame weer te geven. En zonder V-Sync krijg je tearing, dus het frame van tick 29 deels met het nieuwe frame.

Maar vsync is ook zonder drops vervelend, door de extra vertraging. Terwijl je toch zou zeggen dat het minder dan 1/60 sec extra vertraging hoeft te geven, waarschijnlijk minder. Tenzij amd en nvidia de queue aan extra gebufferde frames helemaal vol laten lopen.

In het techreport artikel stond eerst dat amd triple buffering, vsync + refreshrate manipulatie gebruikte voor hun demo, dus dacht ik dat het resultaat identiek zou zijn aan 60 fps zonder drops, met vsync. Maar dat artikel is ondertussen aangepast, en dat lijkt niet het geval te zijn.

[Werelds]

haarbal schreef op donderdag 09 januari 2014 @ 17:42:
Maar vsync is ook zonder drops vervelend, door de extra vertraging. Terwijl je toch zou zeggen dat het minder dan 1/60 sec extra vertraging hoeft te geven, waarschijnlijk minder. Tenzij amd en nvidia de queue aan extra gebufferde frames helemaal vol laten lopen.

Dat is ook het geval bij V-Sync, tot op zekere hoogte. En AMD zal zeker triple buffering gebruiken bij FreeSync, doet Nvidia ook wel bij G-Sync (leg het zo uit). Al het onderstaande baseer ik even op 60 Hz, maar het is natuurlijk even goed toe te passen op 120, 144, 75, 600 of welke refresh rate dan ook, de cijfertjes veranderen alleen. Kleine waarschuwing: lange lap tekst hieronder, maar hopelijk vind je het interessant (en anderen wellicht ook).


Term vooraf: een framebuffer is niets meer dan een stukje geheugen dat wordt gereserveerd voor een gerenderd frame. Voor 1920x1080 bij 24 bits per pixels wordt dat 1920 * 1080 * 24 / 8 = 6220800 bytes ofwel pakweg 6 MB. Dit zit bijvoorbeeld op geheugen adres 0x0000 000. Bij double buffering wordt er een tweede stuk geheugen gereserveerd op 005E EC01 (byte 6220801), bij triple buffering nog een derde 6220800 bytes verderop. Deze adressen zijn natuurlijk geheel fictief, maar dat is de theorie erachter.

Bij enkel-gebufferde V-Sync is de vertraging per frame maximaal 1000 / 60 = 16.67ms. Echter moet de GPU ook wachten met het volgende frame te renderen tot die vertraging om is; dus het volgende frame wordt onnodig vertraagd. Om nu even een situatie zoals hierboven als voorbeeld te blijven gebruiken zal frame 30, dat op 503ms klaar is pas op 516.77ms te zien zijn op je scherm. De GPU mag ook pas op 516.77 het volgende frame (#31) gaan renderen. Wellicht duurt #31 echter maar 8ms om te renderen, wat betekent dat hij eigenlijk ook op tick 31 op je scherm had kunnen verschijnen - omdat hij al klaar HAD kunnen zijn op 503 + 8 = 511ms.

Het omgekeerde kan ook, dat het frame wellicht 20ms nodig had gehad. Dan was het klaar geweest op 503 + 20 = 523ms, wat op tijd geweest zou kunnen zijn voor tick #32 (32 * 16.67 = 533.44ms). Echter mag hij pas beginnen op 516.77, wat betekent dat het frame klaar is op 536.77ms en dus pas op 550.11ms te zien is na wederom bij 14ms vertraging. Dan krijg je over 2 frames maar liefst 30ms vertraging.

Met single-buffered V-Sync mag dat dus niet. Met double buffered wel, want terwijl hij moet wachten op de refresh (VBLANK) mag hij al het volgende frame gaan renderen naar die tweede framebuffer. Dus als hij op 503ms klaar is met frame 30, schrijft hij dat weg naar framebuffer 1 en begint aan het volgende frame en schrijft dat weg naar framebuffer 2.

Dat gaat een tijd goed, maar als je regelmatig van die frames van 20ms hebt (1000 / 20 = 50 FPS voor de duidelijkheid), krijg je op een gegeven moment toch weer een verloop qua rendertijden. Dan zit je op een gegeven moment weer op een punt waarop je tweede framebuffer nog niet leeg gemaakt is, maar de GPU wel een frame klaar heeft. Dan mag hij alsnog niets wegschrijven.

En dat is waar triple buffering voor is. Bij triple buffering is er _altijd_ een buffer vrij; als de tweede buffer nog niet leeg is gemaakt, wordt hij gewoon gewisseld met de derde. De tweede wordt de derde en daar mag dan overheen geschreven worden. Betekent ook dat wat in de tweede buffer zat gewoon weg wordt gegooid, is immers toch niet meer relevant, is al 16.67ms "verouderd". Bekijk het maar als glazen bier die constant gevuld worden waarbij jij alleen uit het eerste drinkt. Het eerste glas wordt altijd vanuit het tweede glas bijgevuld, maar dat tweede glas wordt omgewisseld met het derde glas als jij te traag uit het eerste drinkt. Dat schudden ze dan weg () en tappen een vers glas en zetten dat weer achteraan. Zo zit er in het tweede glas altijd het meest verse bier.


In alle drie de situaties heb je echter minimaal tussen de 0 en 16.67ms vertraging omdat het frame in een buffer zit te wachten tot VBLANK plaats vindt. Daar bovenop krijg je dan nog de vertraging van het LCD paneel. De V-Sync vertraging op zich is dan misschien niet meer dan 16.67, maar samen met het LCD paneel kan dat zomaar 25ms worden.

Waarom gebruiken Nvidia en AMD dan toch nog triple buffering by Free-/G-Sync (dat stond ook ergens in een van de G-Sync artikelen overigens)? Omdat ze anders ook alsnog moeten wachten tot het frame verzonden is naar de monitor, dat 2, 5, 8 ms kan duren afhankelijk van hoe snel het monitor paneel klaar kan zijn - dat is niet iets waar de G-Sync controller controle over heeft, dat ligt puur bij het LCD paneel. Met double buffering lopen ze dan ook nog steeds tot die "race" conditie aan waar ze wellicht te snel klaar zijn.

Disclaimer: ik heb me wellicht ergens verrekend, correct me please

[ Voor 4% gewijzigd door Werelds op 09-01-2014 20:14 ]

[Help!!!!]

Astennu schreef op donderdag 09 januari 2014 @ 14:32:
Tja met UHD kun je AA uit laten bespaart weer wat. En beeld is dan beter dan met een lagere reso en AA. Dat is vooral de rede dat ik naar UHD wil. Gewoon een stukje scherpte er bij. Het is wel veel zwaarder maar je krijgt er ook wat voor terug. En sommige detail settings hakken wel flink in de FPS zonder dat je er veel van ziet. Dus voor mij hoeft niet alles vol uit. Als het qua FPS kan doe ik het wel maar bepaalde dingen zoals SSOA zet ik regelmatig uit.

En met een mooie R9 290X2 kaart er in kun je wel een eindje komen. Ben benieuwd of en wanneer ze uit komen. En of het gerucht van die 30xx shaders waar is. alle shaders aan op lagere clocks is best een manier om de prestaties op te krikken zonder het verbruik extreem omhoog te pushen. Gewoon op 900 MHz clocken met een lager voltage en dan kun je wel binnen het TDP van de 7990 blijven.

Zit wat in heb alleen slecht nieuws voor je. De goedkope dell heeft slechts 30hz op UHD.....
http://www.forbes.com/sit...-4k-monitor-its-only-699/

@ Werelds
Thx. Interessante posts.

[haarbal]

Werelds schreef op donderdag 09 januari 2014 @ 20:10:
[...]

Volgens mij komt het grootste verschil met vsync qua lag vanwege de flip queue / pre rendered frames die standaard op 3 staat, hoewel sommige spellen het vast lager hebben staan.

[Sn0wblind]

Help!!!! schreef op donderdag 09 januari 2014 @ 20:17:
[...]

Zit wat in heb alleen slecht nieuws voor je. De goedkope dell heeft slechts 30hz op UHD.....
http://www.forbes.com/sit...-4k-monitor-its-only-699/

@ Werelds
Thx. Interessante posts.

Heeft dit ook niet met de gebruikte HDMI standaard etc te maken?

[Astennu]

Help!!!! schreef op donderdag 09 januari 2014 @ 20:17:
[...]

Zit wat in heb alleen slecht nieuws voor je. De goedkope dell heeft slechts 30hz op UHD.....
http://www.forbes.com/sit...-4k-monitor-its-only-699/

@ Werelds
Thx. Interessante posts.

Ik had het al gehoord ja dat wordt hem dus niet.

En inderdaad een interessante post van Werelds

[Werelds]

haarbal schreef op donderdag 09 januari 2014 @ 21:37:
Volgens mij komt het grootste verschil met vsync qua lag vanwege de flip queue / pre rendered frames die standaard op 3 staat, hoewel sommige spellen het vast lager hebben staan.

Dat staat los van V-Sync. Render-ahead is geen onderdeel van V-Sync, dat is iets dat men bedacht heeft om framerates vloeiender te maken. Gebeurt dan ook niet op de GPU; pre-"rendering" is alleen de CPU die de data van X frames voor de GPU klaar maakt. Het daadwerkelijke renderen gebeurt vervolgens gewoon volgens schema, dus daar krijg je inderdaad veel lag door

Maar dat kun je voor de meeste games toch wel forceren

[madmaxnl]

Ook wel leuk materiaal voor hier denk ik.
madmaxnl in "[Algemeen] AMD nieuwsdiscussie topic - deel 34"

[Help!!!!]

^
"Nvidia vindt de kritiek die het van veel eindgebruikers krijgt, dat men de technologie gratis zou moeten licenseren aan AMD en andere, onterecht"

Het is voor mij nog onduidelijk of nVidia nu echt iets bijzonders heeft gedaan of dat dit al in een komende DP/Vesa standaard zou zitten.

Stel nu dat ze inderdaad iets bijzonders bedacht hebben dan denk ik dat niemand het onredelijk zou vinden als ze e.e.a. voor een redelijk bedrag zouden licenseren.

Dat "gratis" is gewoon gelul. De mensen vragen dat niet en vallen daar niet over maar wel over de nVidia only Vendorlockin bullshit...

[RnwY]

Volgens Charlie Demerjian heeft AMD bijgedragen aan een VESA standaard, wellicht komt hieruit de FreeSync functie voort.
bron, http://semiaccurate.com/2...ems-vesa-display-id-v1-3/

[Toettoetdaan]

RnwY schreef op vrijdag 10 januari 2014 @ 13:39:
Volgens Charlie Demerjian heeft AMD bijgedragen aan een VESA standaard, wellicht komt hieruit de FreeSync functie voort.
bron, http://semiaccurate.com/2...ems-vesa-display-id-v1-3/

Nope, dat is trouwens ook niet de display poort standaard, maar de display ID standaard. (hoe verwarrend ook die v1.3 is )
Die display ID standaard is zodat we van 4K kunnen genieten op iets beters dan 24Hz, en zodat AMD eyefinity setups kan maken van 6 4k schermen. Omdat de huidige display ID standaard maar tot 2560 * 1600 gaat moeten ze schermen daarboven virtueel opsplitsen in 2 scherm, dus kun je nog maar de helft van het maximum aantal schermen aansluiten op je GPU, omdat 4k schermen tellen voor twee schermen.
(naast dat het wat CF issues geeft)

FreeSync/VBLANK zit al veel langer in een van de standaarden van VESA (ze hebben er veel), voornamelijk bedoeld om energie te besparen op mobiele apparaten. Het lijkt me wel aannemelijk dat AMD er wat druk achter heeft gezet om het naar de DP 1.3a standaard te krijgen, maar het kan net zo makkelijk zijn dat VESA dat toch al van plan was om niet te veel verschil tussen DP en eDP te laten ontstaan.

[enchion]

RnwY schreef op vrijdag 10 januari 2014 @ 13:39:
Volgens Charlie Demerjian heeft AMD bijgedragen aan een VESA standaard, wellicht komt hieruit de FreeSync functie voort.
bron, http://semiaccurate.com/2...ems-vesa-display-id-v1-3/

Uit de tekst
On top of that if you have an AMD card that is Eyefinity capable, that would be just about all of them in the HD6000, HD7000, HD8000, and Rx lines, there are more goodies in store for you. AMD can use the Tiled Display Topology Data Block to do plug and play Eyefinity configuration. Better yet this will allow future tiled displays to be autoconfigured without the current monitor specific driver patches that make things miserable now. In general things should just work.

Maw eerst maak je een oplossing voor alles in je hardware, daarna pas wanneer er genoeg van die hardware rondzwerft in de userbase geef je de "standaard" vrij om voor iedereen te gebruiken. (liefdadigheid ten top. )

Niet zo vreemd dan dat Nvidia dit geintje van AMD wil party-poopen met z`n eigenscaler/Gsync.

[haarbal]

Werelds schreef op vrijdag 10 januari 2014 @ 10:06:
[...]

Dat staat los van V-Sync. Render-ahead is geen onderdeel van V-Sync, dat is iets dat men bedacht heeft om framerates vloeiender te maken. Gebeurt dan ook niet op de GPU; pre-"rendering" is alleen de CPU die de data van X frames voor de GPU klaar maakt. Het daadwerkelijke renderen gebeurt vervolgens gewoon volgens schema, dus daar krijg je inderdaad veel lag door

Maar dat kun je voor de meeste games toch wel forceren

Maar met double buffer vsync krijg je dus dat die queue vol loopt en de lag verschrikkelijk is. Maar goed, blijft een tradeoff.

madmaxnl schreef op vrijdag 10 januari 2014 @ 12:53:
Ook wel leuk materiaal voor hier denk ik.
madmaxnl in "[Algemeen] AMD nieuwsdiscussie topic - deel 34"

Mantle verlaagt vooral de cpu overhead die directx je geeft, hopelijk heb je hierdoor niet meer meerdere pre rendered frames nodig. Als je naar die benchmark grafiekjes kijkt zie je met een apu (met relatief zwakke cpu) dat de winsten gigantisch zijn. Ook zie je dat de apu en de veel snellere intel cpu identiek presteren met een dedicated gpu, dus mantle heeft het spel op de relatief zwakke cpu alsnog gpu limited gekregen.

Sommige spellen zullen er veel aan hebben, andere spellen als arma en total war waarschijnlijk niets, aangezien die cpu limited zijn in hun gevechtssimulatie en niet de directx overhead. Hoewel je in arma misschien de viewdistance op max zou kunnen zetten met mantle, maar goed, bohemia gaat het toch niet implementeren, dus we zullen het waarschijnlijk nooit weten.

[enchion]

RnwY schreef op vrijdag 10 januari 2014 @ 13:39:
Volgens Charlie Demerjian heeft AMD bijgedragen aan een VESA standaard, wellicht komt hieruit de FreeSync functie voort.
bron, http://semiaccurate.com/2...ems-vesa-display-id-v1-3/

btw ik lees hier dat sommigen "Semiaccurate" graag met een schep zout eten.
http://forums.guru3d.com/...php?t=311617&pp=25&page=2

Maar het was wel een leuk artikel en het geeft wat meer ideetjes over wat voor soort dingen gaande zouden kunnen zijn.

[haarbal]

Dat variabele vblank in de standaard staat betekent niet dat we gelijk allemaal monitoren gaan zien met variabele refresh, het is optioneel, zou wel mooi zijn natuurlijk.

Dat artikel gaat er over dat je met 1.3 eindelijk op een normale manier 4k op 60hz kan gebruiken zonder multi stream transport (via eyefinity/surround van 2 outputs 1 beeld maken).

[dahakon]

enchion schreef op vrijdag 10 januari 2014 @ 14:50:
[...]


btw ik lees hier dat sommigen "Semiaccurate" graag met een schep zout eten.
http://forums.guru3d.com/...php?t=311617&pp=25&page=2

Maar het was wel een leuk artikel en het geeft wat meer ideetjes over wat voor soort dingen gaande zouden kunnen zijn.

Grappig, dat draadje gaat over het sluiten van SemiAccurate in een volgend jaar, maar het draadje stamt uit 2009, ondertussen ruim 4 jaar geleden. Bovendien is ondertussen, lijkt mij in ieder geval, bekend dat Charlie een heleboel informatie over Fermi behoorlijk correct had, maar de bashers van S|A hoor je daar in retrospect nooit over. Zelfs niet met een 'met de informatie van nu...' stijl indekking.

Enfin, FreeSync is slechts 1 van vele 'open' standaarden die AMD aan het pushen is, voor de technology-markt, waar zij dan ook van kunnen profiteren.

[Werelds]

enchion schreef op vrijdag 10 januari 2014 @ 13:57:
Maw eerst maak je een oplossing voor alles in je hardware, daarna pas wanneer er genoeg van die hardware rondzwerft in de userbase geef je de "standaard" vrij om voor iedereen te gebruiken. (liefdadigheid ten top. )

Niet zo vreemd dan dat Nvidia dit geintje van AMD wil party-poopen met z`n eigenscaler/Gsync.

Heh? Welke hardware heb jij het over? Wat AMD heeft gebruikt is een standaard uit 2011 en vereist alleen software updates. Ze hebben helemaal geen nieuwe standaard ontwikkeld, gaan dat ook niet doen.

Leuke poging, maar helaas pindakaas.

FreeSync is slechts een demonstratie van wat er met eDP al sinds 2011 kan, het is geen naam voor een nieuwe standaard. Het is de naam die momenteel voor deze feature in hun driver gebruikt wordt.

haarbal schreef op vrijdag 10 januari 2014 @ 15:09:
Dat variabele vblank in de standaard staat betekent niet dat we gelijk allemaal monitoren gaan zien met variabele refresh, het is optioneel, zou wel mooi zijn natuurlijk.

Tuurlijk. Neemt niet weg dat het ook duidelijk is waar Nvidia het idee vandaan heeft en daar zijn ze goed op ingesprongen. Het betekent echter ook, zoals ik zei, dat de echte monitor fabrikanten liever aan de "bestaande" standaard gaan hangen.

[ Voor 7% gewijzigd door Werelds op 11-01-2014 14:08 ]

[Toettoetdaan]

Catalyst 14.1 gaat best vet zijn: http://ces.zol.com.cn/4266765.html

[LongBowNL]

En het feit dat het 14.1 heet, kunnen we het nog in januari verwachten. (Hoop ik ten minste)

[deraco96]

Ik ben wel benieuwd hoe ze Crossfire met Eyefinity gaan oplossen.
Ik krijg wel langzamerhand weer het gevoel, met Free Sync, de 290 met uitstekend werkende multi-GPU, en de gewoon goede prijzen in het midrange 100-200 euro dat AMD weer in de lift zit, al was het alleen maar op Tweakers.net...
Ik ben wel benieuwd hoe lang het gaat duren om een monitor goedkoop met een 'sync' oplossing uit te gaan rusten, het is namelijk ideaal voor budgetgaming, of gewoon in het algemeen het maximale uit je kaart te halen. Nu is het namelijk zo dat als je V-Sync wil (wat ik wel heel graag draai, inputlag merk ik nooit zo, tearing des te erger) je wel graag wat extra power wil hebben om maar geen drops net onder de 60 te krijgen. Met sync zou je je PC gewoon vrolijk tussen de 40 en 60FPS kunnen laten lopen, dus goedkopere GPU's of hogere instellingen...
Eigenlijk ben ik sowieso toe aan een nieuwe monitor, ik doe het nog met 226BW's... Daarom hoop ik ook dat ze een beetje opschieten. Ik heb nu noodgedwongen nVidia (heb de hele rant hier geloof ik al eens gepost) dus G-Sync zou in theorie ook volstaan, maar dat belooft weer goed duur te worden, nVidia kennende.

[BarryKohne]

http://wccftech.com/amd-c...january-kaveri-coprocess/

[ Voor 38% gewijzigd door BarryKohne op 16-01-2014 23:22 ]

[Astennu]

Dual graphics frame pacing. Ik gok dat het hier dan gaat over 79xx kaarten? (of in ieder geval niet de R9 290 en R9 260 kaarten met de hw crossfire engine)
Ik dacht dat dit ook al in cat 13.12 zat. (het zat in ieder geval al in de 13.10 beta en de 13.11 beta)
Ik vraag me af of dit dan ook voor Eyefinity en 4K is. zal wel niet.

Mooi dat die APU dan voor Physics gebruikt wordt zodat je R9 290X dat niet hoeft te doen. Nu is alleen de vraag of de CPU cores in Kaveri snel genoeg zijn om genoeg data aan te leveren zodat die R9 290X ook echt vol belast kan worden. Met Mantle denk ik wel. Maar met DirectX zal dat wel lastig worden. Tenzij je meer kan offloaden naar de GPU op in de APU.

Edit:

Heb even op mijn Mining Rig gekeken met 1x7970 en 1x7990 daar zie ik geen framepacing staan. Kan zijn doordat het 3 kaarten zijn.

Ik kan wel dit op internet vinden in de releasenotes van 13.12:

Support For AMD CrossFire frame pacing
Frame pacing ensures that frames rendered across multiple GPUs in an AMD CrossFire configuration will be displayed at an even and regular pace
Frame pacing is enabled through the AMD Catalyst Control Center, or on a per application basis
Frame pacing is supported on DirectX 10 and DirectX 11 applications using resolutions up to (and including) 2560x1600 on a single display

Dus ik denk dat ze het gewoon opnieuw noemen voor de marketing. En dat het bij mijn mining pc niet zichtbaar is doordat het 3 kaarten zijn en de CF bridge er niet tussen zit.

[ Voor 72% gewijzigd door Astennu op 17-01-2014 08:48 ]

[Indy91]

Kaveri beta support coming end of January (13.35 driver).

Dus AMD Mantle binnen 2 weken beschikbaar via 14.1 BETA. :

[Astennu]

Zal wel moeten voor BF4 hopelijk wordt het niet weer uitgesteld....

[Recon24]

Ik ben van plan de MSI 280X Gaming 3G aan te schaffen, maar op het moment is hij nog niet super leverbaar. Ook heb ik een nieuwe kast nodig zodat ik mijn H100i helemaal optimaal kan gebruiken en ook push/pull config kan samenstellen (waarschijnlijk de Corsair Obsidian 750D).

Zodra deze MSI 280X beter leverbaar is zal hij ook wel hier en daar goedkoper leverbaar zijn. heeft iedere MSI 280X de nieuwe XTL chip aan boord?

[evilpin0]

BarryKohne schreef op donderdag 16 januari 2014 @ 23:16:


http://wccftech.com/amd-c...january-kaveri-coprocess/

Cool! Vraag me af of een intel APU dan ook gebruikt kan worden (denk het niet).

ben ook erg benieuwd naar de verbeterde video afspeel mogelijkheden

[Astennu]

evilpin0 schreef op vrijdag 17 januari 2014 @ 11:11:
[...]


Cool! Vraag me af of een intel APU dan ook gebruikt kan worden (denk het niet).

ben ook erg benieuwd naar de verbeterde video afspeel mogelijkheden

Natuurlijk kan dat niet. Die heeft geen GCN GPU. dat is just het hele idee. Intel is nog niet zo goed in GPGPU. Ze hebben wel larabee maar dat is op basis van X86.
Daarnaast heeft AMD ook nog veel andere dingen in de GPU en APU toegevoegd om die interne GPU met een losse GCN kaart samen te laten werken.

[ Voor 13% gewijzigd door Astennu op 17-01-2014 11:44 ]

[DCG909]

@Astennu.

Ik kan wel gewoon Frame Pacing zien bij 13.12, icm 2x 7970.
Of en hoe het werkt geen idee.... voor mijn gevoel heb ik er niet zoveel last van.

Misschien bedoelen ze dat het nu op zowel DX11 als DX9.0C werkt? en met Eyefinity?

[Astennu]

Eyefinity volgens mij niet. Dat is hetzelfde probleem als met 4K. Crossfire link heeft te weinig bandbreedte om dat goed te kunnen doen. En over de PCI-E bus is lastig omdat ze die Hardware CF engine niet in alle GCN chips hebben zitten.

[DCG909]

Maar werkt 4K dan wel zonder frame pacing?
Zelf zie ik namelijk geen stutteringen bij 1080P.

Ik vraag me overigens wel af wat ze nog kunnen optimaliseren aan CF.

[deraco96]

Recon24 schreef op vrijdag 17 januari 2014 @ 11:00:
Ik ben van plan de MSI 280X Gaming 3G aan te schaffen

Ik weet het, heel erg offtopic, maar weet dan niemand dit? Ik weet het, het forum van LinusTechTips... Maar er is wel een discussie over de resultaten van TechPowerup. De 280X Gaming is namelijk best populair, ik denk ook vanwege de uitstekende resultaten van de Gaming-koelers op andere (nVidia) kaarten, maar hierover zou ik me wel zorgen maken.

[Astennu]

DCG909 schreef op zaterdag 25 januari 2014 @ 16:59:
Maar werkt 4K dan wel zonder frame pacing?
Zelf zie ik namelijk geen stutteringen bij 1080P.

Ik vraag me overigens wel af wat ze nog kunnen optimaliseren aan CF.

4K werkt Maar je heb geen Frame Pacing. Een resolutie boven 2560x1600 is op dit moment een probleem. Als je dat wilt moet je naar R9 290X kaarten die hebben er geen last van.

1080p zou perfect moeten werken. Bij welk spel heb je er last van? heb je frame pacing aan staan in de driver/ je kan het aan en uit zetten.

[DCG909]

Het enige spel waar ik iets bij zie is Audiosurf 2.
Maar daar lijkt Vsync o.a. gewoon niet te werken XD
Ook al forceer ik dat, dan nog kakt mijn CF setup gewoon 700 FPS uit.
Daar zie ik dus onderaan wat imperfecties...

Maar ik ga er vanuit dat dat meer komt door de idioot hoge FPS.

Hmmm, bedenk me nu net dat ik eens kan proberen Frame Pacing uit te zetten en dan Vsync te forceren.
Volgens mij is AS 2 een DX9.0c game oid, dus dan werkt Frame Pacing hoe dan ook niet...

Bij andere games heb ik echt 0 problemen, zelfs voordat frame pacing in de drivers zat.

[Astennu]

DCG909 schreef op zondag 26 januari 2014 @ 15:59:
Het enige spel waar ik iets bij zie is Audiosurf 2.
Maar daar lijkt Vsync o.a. gewoon niet te werken XD
Ook al forceer ik dat, dan nog kakt mijn CF setup gewoon 700 FPS uit.
Daar zie ik dus onderaan wat imperfecties...

Maar ik ga er vanuit dat dat meer komt door de idioot hoge FPS.

Hmmm, bedenk me nu net dat ik eens kan proberen Frame Pacing uit te zetten en dan Vsync te forceren.
Volgens mij is AS 2 een DX9.0c game oid, dus dan werkt Frame Pacing hoe dan ook niet...

Bij andere games heb ik echt 0 problemen, zelfs voordat frame pacing in de drivers zat.

Maar dan is het gewoon je scherm. Want die krijg dan stukken van een aantal frames binnen. zonder vsync heb je dat probleem inderdaad ook. (als ik de werking van frame pacing goed begrepen heb)

[BarryKohne]

http://www.pcgameshardwar...es-Nitrous-Video-1104642/

AMD 13.35 driver heeft kortstondig op de Toshiba driver download gestaan.
http://goo.gl/ox7CHp INF aanpassen en driver signature disabelen.

[Indy91]

BarryKohne schreef op maandag 27 januari 2014 @ 22:42:
http://www.pcgameshardwar...es-Nitrous-Video-1104642/

AMD 13.35 driver heeft kortstondig op de Toshiba driver download gestaan.
http://goo.gl/ox7CHp INF aanpassen en driver signature disabelen.

Waar, o waar blijven die AMD 13.35 drivers (met AMD Mantle Patch) nou. Je zou toch mogen verwachten dat de 13.35 drivers die kortstonding op de Toshiba site stonden, een teken aan de wand was.

De AMD 13.35 drivers zouden immers in januari 2014 released worden.

[ Voor 9% gewijzigd door Indy91 op 30-01-2014 12:28 ]

[LongBowNL]

Mantle is live op BF4, alleen de AMD 14.1 beta drivers (met Mantle) zijn op dit moment nog niet beschikbaar.
http://battlelog.battlefi...ews/view/bf4-mantle-live/

Extra info over de driver update: http://www.maximumpc.com/...ng_mantle_update_and_more

1. Mantle performance for the AMD Radeon HD 7000/HD 8000 Series GPUs and AMD Radeon R9 280X and R9 270X GPUs will be optimized for BattleField 4 in future AMD Catalyst releases. These products will see limited gains in BattleField 4 and AMD is currently investigating optimizations for them as they are the next highest priority products.

Meh

[ Voor 58% gewijzigd door LongBowNL op 30-01-2014 12:38 ]

[Astennu]

Ze hebben hun 2e deadline dus toch gehaald.
Wel apart dat de drivers er nu niet klaar voor zouden zijn. Of in ieder geval nog niet optimaal zijn.

Waarmee hebben ze die performance gain's dan getest? drivers die nu dus nog niet beschikbaar zijn? of denken ze er nog meer uit te kunnen halen?

In ieder geval vanavond maar eens proberen op mijn M4000 (7750M).

[Astennu]

Mmmh er is meer interessants:

But wait, there's more! In addition to all this the Catalyst 14.1 drivers will also include AMD's "phase 2" frame pacing driver it promised last year. If you recall, the first release of this driver only supported it on one display up to 2560x1600 resolution. It also only worked on DX11 games. Phase 2 broadens support to DX10 and DX11, and allows resolutions higher than 2560x1600, so those of you with 4K panels will appreciate this update. The update also applies to any GPUs that don't feature AMD's XDNA technology, which are the R9 290 and R9 290X boards (it gets rid of the CrossFire cable as they communicate directly through PCI Express). The driver update also helps frame pacing in dual GPU configurations where an APU is coupled with a GPU.

Finally, the Catalyst 14.1 driver is also the first HSA-enabled driver, which allows Kaveri APUs to intelligently cooperate with a GPU to share the workload. The only supporting applications listed by AMD at this time are LibreOffice v4.2.0.1+ and Core AfterShot Pro v1.2.0.6+, but it says more will come online soon.

Dus Eyefinity users zouden nu ook Frame pacing moeten hebben!

[The Fox NL]

LongBowNL schreef op donderdag 30 januari 2014 @ 12:34:
Mantle is live op BF4, alleen de AMD 14.1 beta drivers (met Mantle) zijn op dit moment nog niet beschikbaar.
http://battlelog.battlefi...ews/view/bf4-mantle-live/

Extra info over de driver update: http://www.maximumpc.com/...ng_mantle_update_and_more


[...]

Meh

Je ziet anders toch een 25% verbetering met een 7970, dus dat limited gains valt wel mee.
Als je de grafiekjes van cpu + gpu tijd ziet in die screenshots, zie je dat ze veel stabieler zijn en minder uitschieters naar boven. Mantle geeft zo te zien een stabielere framerate en hogere minimum framerates.

Jammer dat de driver niet gelijk support voor alle GCN kaarten heeft..

[Astennu]

Ik vind dat het flinke performance gain's zijn. Ook voor de zwaardere CPU's. Ik ben heel benieuwd wat ik merk op mijn Laptop met Core i7 en die 7750M. Ik speel bijna alleen maar 64 player maps. En je merkt dat het bij zware gevechten zelfs met alles op low gewoon zwaar is. (desktop is momenteel out of order)

[henri8096]

The Fox NL schreef op donderdag 30 januari 2014 @ 13:06:
[...]
Jammer dat de driver niet gelijk support voor alle GCN kaarten heeft..

Dat staat er volgens mij niet. Er staat alleen dat de performance in latere Catalyst releases
geoptimaliseerd wordt en op dit moment nog niet de verwachte prestatiewinst oplevert.

Edit:
Helaas het verhaal van DICE/EA spreekt wel van een latere release voor de 7xxx series.

[ Voor 11% gewijzigd door henri8096 op 30-01-2014 13:22 ]

[enchion]

Het grootste verschil door het gebruik van Mantle zal zowiezo binnen 1-2 jaar pas duidelijk worden door de hoeveelheid gebruik binnen de markt.

Het voornaamste verschil zal moeten gaan komen van nu nog pure console-developers die nooit overwogen om naar de PC te gaan omdat ze bij het porten teveel dingen moeten uitschakelen/weglaten, en geen logica/tijd/middelen zien om de hele sourcecode van het spel te gaan ombouwen voor PC.

Met Mantle en HSA zou het voor de consoledevelopers makkelijker moeten worden om crossplatform te gaan releasen, maw Forza,Killzone,enzzz voor de PC.
(oftewel een 1000% tot oneindige performance gain)

Veel pure PC developers kennen de trucjes voor de PC al en zullen niet zoveel winst zien.
(aannemelijk = 10-30% average)

btw
Wel leuk om te zien dat de grootste winst (58%) zelfs met een intel processor behaald wordt en ook dat een 7000 series GPU een aardige winst laat zien.
(dit is misschien wel het meest nieuwswaardige want het laat zien dat ze absoluut niet de weg willen gaan bewandelen dat het alleen met selectief bepaalde AMD-hardware werkt)

[Werelds]

We zullen snel genoeg wat onafhankelijke resultaten zien. Dat 8350+7970 resultaat vind ik erg interessant; 25% is wellicht niet wat sommigen hadden verwacht, ik vind het nog steeds significant. En ik betwijfel ten zeerste of DICE er nu al alles uit krijgt geperst.

[Astennu]

Hybrid Crossfire met Kaveri werkt erg goed!:

http://www.pcper.com/revi...ing-Pacing-Fixed/Battlefi

Als je dan mantle games heb heb je ook weinig last van een tragere CPU. Zou nog best wel eens het beste game platform kunnen worden qua bang for bux.

[Indy91]

Werelds schreef op donderdag 30 januari 2014 @ 14:32:
We zullen snel genoeg wat onafhankelijke resultaten zien. Dat 8350+7970 resultaat vind ik erg interessant; 25% is wellicht niet wat sommigen hadden verwacht, ik vind het nog steeds significant. En ik betwijfel ten zeerste of DICE er nu al alles uit krijgt geperst.

Ik heb tevens een AMD FX8350( @4,4) + HD7970 (OC'ed). Ben benieuwd of ik ook die 25% ook eruit krijg geperst.

Ik zou nochtans erg content zijn als ik die 25% performance gain zou halen.

[mitsumark]

Indy91 schreef op donderdag 30 januari 2014 @ 15:32:
[...]

Ik heb tevens een AMD FX8350( @4,4) + HD7970 (OC'ed). Ben benieuwd of ik ook die 25% ook eruit krijg geperst.

Ik zou nochtans erg content zijn als ik die 25% performance gain zou halen.

Je hebt niet/nauwelijks een cpu bottleneck, dus ik zou op max 10% rekenen.

[Indy91]

mitsumark schreef op donderdag 30 januari 2014 @ 15:44:
[...]

Je hebt niet/nauwelijks een cpu bottleneck, dus ik zou op max 10% rekenen.

Neen, ik reken op 25% of meer!

Test case 2: Standard 64-player multiplayer
CPU: AMD FX-8350, 8 cores @ 4 GHz
GPU: AMD Radeon 7970 3 GB (AMD will add support for the AMD Radeon™ HD 7970 in a later stage of Mantle’s release schedule, learn more)
Settings: 1080p ULTRA 1x MSAA
OS: Windows 8 64-bit
Level: Siege of Shanghai
Level was tested with 64 “pseudo players” that we have for our own internal testing that simulates heavy game workload that we have in multiplayer in order to get more deterministic results compared to full real multiplayer. 64 players on the large Battlefield levels is really demanding of the CPU so this test case is primarily CPU-bound.
Result: 18.87 ms/f -> 15.08 ms/f = 25.1% faster

[Anoniem: 304087]

Kijk eens aan dat zijn toch mooie scores die behaald worden met Mantle. Als ik het probeer te vergelijken is de hd7970 cf bijna net zo snel als de gtx780 sli want daar haalt de gtx780 sli ongeveer de zelfde fps (135fps gemiddeld) en de hd7970 cf gemiddeld 121 fps met 58% prestatie winst op een intel systeem met een i7 3970 3500mhz.

[Phuncz]

Het lijkt me ook logisch dat Mantle voornamelijk voor hun APU's de meeste voordelen oplevert:
- minder "RAW" power van de CPU cores door het gebrek aan optimalisatie vanuit de industrie (voornamelijk Intel)
- CPU + GPU (als APU) die flexibel kunnen werken, maar ook zeer gericht
- de trage/goedkope chipsets (zelfs al verkochte) gaan een flinke boost in performance krijgen, gratis

Als ik zie wat de Catalyst 14.1 allemaal moet verwezenlijken (Mantle, Frame Pacing, HSA) dan vind ik het niet absurd dat ie een paar dagen uitgesteld is.

[ Voor 16% gewijzigd door Phuncz op 30-01-2014 17:59 ]