AMD demonstreert FreeSync-over-hdmi

Door Olaf van Miltenburg, woensdag 3 juni 2015 13:35, 146 reacties • Feedback
Submitter: Sp3ci3s8472

AMD heeft op de Computex in Taiwan laten zien dat zijn FreeSync-technologie ook werkt in combinatie met hdmi. Een standaardmonitor zou alleen nieuwe firmware nodig hebben om dit werkend te krijgen.

AMD demonstreerde FreeSync-over-hdmi bij zijn stand op de Computex in combinatie met een AMD R9 2xx-kaart en een monitor met een standaard-Realtek-tcon. Realtek heeft wel de firmware van de controller aangepast en AMD heeft ondersteuning voor de technologie aan zijn drivers toegevoegd. Bovendien gaat het om een aangepast protocol voor hdmi 1.4a.

Het doel van AMD is waarschijnlijk dat FreeSync deel gaat uitmaken van de hdmi-standaard, schrijft AnandTech. Eerder nam de VESA FreeSync onder de naam Adaptive Sync op in de displayport 1.2a-standaard, al is implementatie van de technologie niet verplicht.

FreeSync is een techniek voor dynamische verversingssnelheid, die ervoor zorgt dat het beeldscherm en de videokaart of apu compleet synchroon werken, zodat tearing en stotteren worden voorkomen. Het is daarmee een open tegenhanger van Nvidia's Gsync, dat een hardwaremodule vereist voor monitors, maar niet voor laptops.

AMD FreeSync-over-hdmi

Reacties (146)

Luukwa
3 juni 2015 13:40

Zou het heel tof vinden als ze zon techniek ook voor nvidia beschikbaar zouden stellen.
Helaas denk ik niet dat dit gaat gebeuren met de huidige shit storm die over GPU-land raast.
We gaan het zien!

Werelds

@Luukwa • 3 juni 2015 13:43

Dat ligt geheel bij Nvidia. Het staat ze vrij om Adaptive Sync te implementeren en mocht AMD dit in de HDMI standaard verwerkt krijgen (waarschijnlijk ook als optie, net als Adaptive Sync), ligt het ook dan gewoon bij Nvidia.

+2 simplicidad
@Werelds • 3 juni 2015 14:39

Nvidia lijkt mij echter wel het laatste bedrijf die ik zie springen om open HW standaarden te implementeren of zelf naar voor te brengen. Het bedrijf doet mij soms vaak denken aan het Microsoft uit de jaren 90 waar ook alles zoveel mogelijk in teken stond van vendor lock-in.

Het is een strategie die hun blijkbaar ook geen windeieren legt en waar ik zelf ook in ben gelopen. Ik heb heel wat CUDA - 3d related - only software en dan is het vaak moeilijk om een non Nvidia kaart te kopen.

G-sync is in deze voor hen veel interessanter omdat als je zo'n monitor koopt je volgende kaart hoogstwaarschijnlijk terug een Nvidia kaart zal zijn, met freesync heb je als consument de keuze.

Nvidia kan op papier veel, maar in realiteit... .

[Reactie gewijzigd door simplicidad op 3 juni 2015 14:43]

+1 Devion
@simplicidad • 3 juni 2015 16:04

Nvidia en Ati liggen wel vaker in de clinch.. Dat GSync propitiatary hardware is, is niet vreemd - Mantle en TressFX waren ook closed source (van ATI), niet zo vreemd dat GSync en Hairworks op dit moment ook niet vrij geshared worden op de markt..

En dat zal wel even duren voordat beide door een deur kunnen..

Sinester
@Devion • 3 juni 2015 16:14

Mantle en TressFX waren ook closed source

Volgens mij zijn die allebei open source en kan iedereen er gebruik van maken

Gsync en Hairworks zou nooit geshared worden, maakt niet uit of Mantle/tressFX Open of Closed is

+1 Scalibq
@Sinester • 3 juni 2015 16:21

Volgens mij zijn die allebei open source en kan iedereen er gebruik van maken

Mantle is niet open source, en AMD heeft ook aangegeven dat ze geen publieke SDK of iets vrij gaan geven.
Ze hebben alleen onder een of andere licentie het een en ander aan Khronos gegeven.
Wat dat precies is, weet niemand, behalve mensen die onder die licentie vallen.

+2 freaq
@Scalibq • 3 juni 2015 20:44

-Mantle is vrij te implementeren voor Nvidia,
echter Nvidia kiest daar niet voor gezien Mantle speciaal gemaakt is om optimaal te presteren op de GCN tech.
-T-ressFX is volledig open source en vrij te gebruiken
-adaptive/(free)sync is ook open en vrij te gebruiken.

AMD maakt practisch al haar tech te gebruiken op beide platformen.
Nvidia is bijna volledig proprietair.

-CUDA
-Gsync
-PhysX (behalve een expres extreem trage CPU versie)
-VXGI

uitzondering is Hairfarm, technisch ook buikbaar op AMD, maar is wel zo gemaakt dat het AMD hardware veel meer impact, en wederom closed source...

OT:
freesync /adaptive sync over HDNI juich ik zeker toe!
}zeker op tv's kan dat ook wel eens de latency positief beinvloeden (door om alle postprocessing bende heen te gaan)

erg prettige ontwikkeling dit!

+1 SG

@freaq • 4 juni 2015 03:37

NV is sterk prestige en imago gericht. Net als iNtel ook hun CPU x86- 64bit machinetaal niet AMD64 noemen.
En dan ook niet hun mytische marketing er op los kunnen laten.
zoals infiniteFX.
De meeste bedrijven laten standaarden van concurrent liever links liggen.

+1 Scalibq
@SG • 5 juni 2015 11:34

NV is sterk prestige en imago gericht. Net als iNtel ook hun CPU x86- 64bit machinetaal niet AMD64 noemen.

En AMD heeft het nooit over IA-32, wat de 'juiste' naam is voor x86 (Intel Architecture 32-bit): http://en.wikipedia.org/wiki/IA-32

+1 Pb Pomper
@Scalibq • 4 juni 2015 01:03

[...]

Mantle is niet open source, en AMD heeft ook aangegeven dat ze geen publieke SDK of iets vrij gaan geven.

"We'll be releasing a public SDK later this year, and hope that others adopt it. If they don't adopt it itself, then we hope they adopt APIs similar to it that become an industry standard for PC gaming."

bron

+2 Scalibq
@Pb Pomper • 4 juni 2015 09:21

Dat is verouderde info.
Dit is nieuwer:
https://community.amd.com...-and-the-future-of-mantle

Mantle’s definition of “open” must widen.
...
The Mantle SDK also remains available to partners who register in this co-development and evaluation program. However, if you are a developer interested in Mantle "1.0" functionality, we suggest that you focus your attention on DirectX® 12 or GLnext.

Kortom: Alleen voor mensen die geregistreerd zijn (en ik heb het geprobeerd, maar ik werd niet toegelaten, dus het is zeker niet voor iedereen).
De rest heeft pech, en zoals AMD al zegt, doe maar DX12 of GLnext/Vulkan.
Ze hebben dus het idee van de public SDK geschrapt.

+1 freaq
@Scalibq • 4 juni 2015 19:33

ze hebben er met mantle anders wel voor gezorgd dat er eindelijk low level API's komen, zonder Mantle had MS nooit DX12 gemaakt zoals het nu is, zelfde voor VUlkan/OpenGL Next

we mogen AMD zeker dankbaar zijn, en ik vind het ergends jammer dat ze niet direct baat hebben bij hun investering, zeker gezien ze krap bij kas zitten.

+1 Scalibq
@freaq • 4 juni 2015 19:59

ze hebben er met mantle anders wel voor gezorgd dat er eindelijk low level API's komen, zonder Mantle had MS nooit DX12 gemaakt zoals het nu is, zelfde voor VUlkan/OpenGL Next

Dat zegt iedereen wel zo makkelijk, maar zoals ik al zo vaak heb beargumenteerd, is het niet zo simpel.
Ik ga het hier niet voor de zoveelste keer herhalen, zoek zelf maar terug in andere reacties etc.

[Reactie gewijzigd door Scalibq op 4 juni 2015 19:59]

+1 freaq
@Scalibq • 4 juni 2015 20:13

je begrijpt me verkeerd.
ja AMD zal mantle inderdaad abandonen.
ik spreek je daarin helemaal niet tegen.

maar had AMD nooit mantle gemaakt hadden we geen
-DX12
-Metal
-GLNext
en tig andere research naar low level API's gehad...
daar mogen we AMD zeker wel voor bedanken,
zeker gezien ze zelf weinig vruchten pikken van deze revolutie (want dat is het)

+1 Scalibq
@freaq • 4 juni 2015 20:36

maar had AMD nooit mantle gemaakt hadden we geen
-DX12
-Metal
-GLNext
en tig andere research naar low level API's gehad...

Jij stelde dat in je vorige post ook al, en ik zei al dat ik het daar niet mee eens was. Je herhaalt het weer, zonder enige argumentatie.

+1 freaq
@Scalibq • 4 juni 2015 20:40

ok prima,

hoeveel low level API's waren er voor Mantle?
-alleen die op consoles

hoeveel na Mantle
-tientallen.

vrij basic oorzaak gevolg?
men zag in door deze low level API dat het wedegelijk mogelijk was op PC, en dat het enorme winst kan boeken.

Ik snap niet waarom je overigends zo enorm adverseriaal bent. het is niet alsof ik je persoonlijk aanval ofzo...

verder als je nog een bron zoekt:
http://www.tomshardware.c...n-graphics-api,28678.html

[Reactie gewijzigd door freaq op 4 juni 2015 20:44]

+1 Scalibq
@freaq • 4 juni 2015 21:05

hoeveel low level API's waren er voor Mantle?
-alleen die op consoles

Vergeet je dingen als Glide, PowerSGL etc? Of zelfs de eerste versies van DirectX? In feite had MS altijd al gelijk gehad met hun aanpak van execute buffers, en zijn we nu weer terug bij af.

vrij basic oorzaak gevolg?

Nee, correllation does not imply causation: http://en.wikipedia.org/w..._does_not_imply_causation

[Reactie gewijzigd door Scalibq op 4 juni 2015 21:07]

+1 freaq
@Scalibq • 4 juni 2015 22:08

ik vergeet dat absoluut niet, echter daar is verder en verder vanaf geweken, voor steeds meer abstractielagen,
en Mantale was de eerste welke wederom demonstreerde dat dat dus niet perse nodig meer is gezien GPU's nu programmable zijn.

correlation does not always imply causation.
maar regelmatig ook wel.

en in dit geval is het heel erg duidelijk dat Mantle de eerste moderne Low Level API was. en dat velen daarna volgden.

en het is niet dat ik de enige ben met deze mening
verder als jke kijkt naar DX12 is het heel erg gemodelleerd naar hoe Mantle ook intern werkt, is dat toeval? betwijfel het.

AMD heeft ook nauw samengewerkt met MS aan DX12 en heeft gezien de open natuur het MS ook makkelijk gemaakt om in te zien wat wel en niet goed werkt bij Mantle.

nee DX12 is niet mantle
Vulkan is ook niet mantle,
en ja beide zijn meer cross platform dan mantle ooit was.
dat gezegd hebbende hebben beide duidelijk wel gekeken naar wat mantle deed.

maargoed als jj bewijs hebt om te denkden dan DX12 Metal en GLNext/Vulkan niet beinvloed/geinspireerd zijn door mantle zou ik dat graag zien...

[Reactie gewijzigd door freaq op 4 juni 2015 22:10]

+1 Scalibq
@freaq • 4 juni 2015 22:22

en Mantale was de eerste welke wederom demonstreerde dat dat dus niet perse nodig meer is gezien GPU's nu programmable zijn.
...
en in dit geval is het heel erg duidelijk dat Mantle de eerste moderne Low Level API was. en dat velen daarna volgden.

Mijn punt is dus dat hoewel Mantle de eerste was die via een grote marketing-campagne de wereld in is geslingerd, maanden voordat er ook maar *iets* van te zien was, dat dat niet per se betekent dat Mantle ook de eerste was met die ideeen.

en het is niet dat ik de enige ben met deze mening
verder als jke kijkt naar DX12 is het heel erg gemodelleerd naar hoe Mantle ook intern werkt, is dat toeval? betwijfel het.

Ten eerste, waar baseer jij dat op? Weet jij hoe DX12 en Mantle intern werken? En in hoeverre lijken ze dan op elkaar?

Ten tweede, heb je ooit gedacht aan de mogelijkheid dat de ontwikkeling van DX12 eerder begonnen is dan Mantle, en dat Mantle juist gemodelleerd is op de ideeen van DX12?

[Reactie gewijzigd door Scalibq op 4 juni 2015 22:42]

+1 freaq
@Scalibq • 4 juni 2015 22:28

mischien omdat ik een gamedeveloper ben?
en verder heb ik hier een bron welke ik al eerder gepost heb:

http://www.tomshardware.c...n-graphics-api,28678.html

When AMD announced the Mantle API that was "closer to the metal" than either OpenGL or DirectX in order to cut significant driver overhead and increase performance, many were skeptical, or even hostile toward AMD's mission.

Many believed that AMD might cause a fragmentation in the graphics API world, and that Intel or Nvidia would rather create their own APIs than work with AMD on Mantle, even if AMD extended an open invitation to all the other chip makers to join them and evolve the API together.

The risk wasn't non-existent, however the potential upside -- forcing Khronos and Microsoft to rethink their graphics APIs and tap into the hardware's full potential, much like you would with a console -- was too great to pass.

In the end, AMD's Mantle ended up fostering a revamping of everyone's graphics API, fearing that they would be replaced. Now both the new Vulkan API and DirectX 12 are heavily inspired by Mantle. And instead of creating fragmentation, we're getting much better standardized graphics APIs that perhaps we wouldn't have gotten in such a short period of time otherwise.

nog een leuke bron:
http://www.pcworld.com/ar...as-opengls-successor.html

“The cross-vendor Khronos Group has chosen the best and brightest parts of Mantle to serve as the foundation for 'Vulkan,' the exciting next version of the storied OpenGL API,” Hallock wrote. “Vulkan combines and extensively iterates on (Mantle’s) characteristics as one new and uniquely powerful graphics API. And as the product of an incredible collaboration between many industry hardware and software vendors, Vulkan paves the way for a renaissance in cross-platform and cross-vendor PC games with exceptional performance, image quality and features.”

indicatie dat er iig bij Vulkan significant naar gekeken is.
MS gaat nooit direct zeggen dank AMD,

maar mantle is inmiddels al een paar jaar oud, en deze nieuwe API's zijn nog niet af, dus tenzij je specifiek bewijs hebt dat DX12 al significant ver in de ontwikkeling was voor de aankondiging van Mantle mogen we zeker aannemen dan MS heeft toegegeken (mogelijk al hetzelfde idee hebbende das prima mogelijk) en zag dat het werkt, wat ook helpt met de pitch.

AMD was de eerste met een low level moderne API
en er komen nu vele anderen,
oorzaak of niet AMD was de eerste, en heeft het makkelijker gemaakt door code vrij te geven, en door te bewijzen dat het kan.

sorry maar daar is echt vrij weinig tegen in te brengen.
en ik geef het verder op als je het hierna nog niet met je eens bent.

maar ik vraag je wel om dan met wat bewijs van jouw kant te komen, want ik heb niet gevonden dat indicatie geeft dat DX12 al echt ver gevorderd was toen AMD met mantle kwam

je vraagt mij steeds om bewijs, ik heb het denk ik wel gegeven, jouw beurt als je echt me wil overtuigen...

[Reactie gewijzigd door freaq op 4 juni 2015 22:37]

+1 Scalibq
@freaq • 4 juni 2015 22:39

mischien omdat ik een gamedeveloper ben?

Ik ook. Zit jij in het DX12 early access program? Ik wel, namelijk.

en verder heb ik hier een bron welke ik al eerder gepost heb:

Tsja, het was nogal een inkoppertle dat nVidia en Intel niet met AMD gingen samenwerken. Zelfs AMD had dat van te voren al moeten weten.
Daarom zei ik dus al dat het vreemd van AMD is om het eerst als Mantle op de markt te brengen, met een aantal games, en daarna pas naar Khronos te stappen, waar dan weer Vulkan uit voortkomt.

Verder is die bron onzinnig. Die claim dat DX12 geinspireerd is op Mantle komt uiteindelijk bij AMD vandaan, en is door een hoop tech-sites gewoon klakkeloos overgenomen. Dus ja, je kunt genoeg 'bronnen' vinden op internet.
Dat maakt het nog niet waar. Vraag het Microsoft, Intel of nVidia eens.

[Reactie gewijzigd door Scalibq op 4 juni 2015 22:39]

+1 Pb Pomper
@Scalibq • 5 juni 2015 10:17

Dat maakt het nog niet waar. Vraag het Microsoft, Intel of nVidia eens.

nVidia is de laatste die daar eerlijk antwoord op zou geven. Ik heb zelden zo'n zelfingenomen, kinderachtig en koppig bedrijf gezien.

Te trots om toe te geven dat hun concurrent gewoon een goed idee heeft waar de consument enorm veel baat bij heeft. En vervolgens wel de loftrompet opsteken over DirectX12 (wat nota bene zwaar gebaseerd is op AMDs innovatie) en hun eigen proprietary standaaden (de horror physx en gameworks).

Ik ben nog steeds van mening dat een hardwarefabrikant zich bezig moet houden met het ontwikkelen van hardware. Natuurlijk moeten ze wel samenwerken om de performance te optimaliseren (API, drivers, etc). Maar ik vind het een slechte zaak dat nVidia steeds meer met eigen "innovaties" komt. Ze zeggen doodleuk dat AMD dan ook maar zelf hun eigen dingen moeten gaan ontwikkelen. NEE NVIDIA! Ik weet dat jullie geen ene kloot geven om de gamer, ook al doe je voorkomen dat nVidia alleen uit gamers bestaat. Dit is precies waar de consumnet niets aan heeft.

+1 Scalibq
@Pb Pomper • 5 juni 2015 10:22

(wat nota bene zwaar gebaseerd is op AMDs innovatie)

Ja, daar is iedereen wel van overtuigd. Ondanks dat het niet waar is.
AMD heeft gewoon de ideeen van Microsoft en Sony 'geleend' voor Mantle, en heeft ze iets eerder op de markt weten te pushen dan DX12 (maar dan wel in gesloten beta-vorm).

Ik ben nog steeds van mening dat een hardwarefabrikant zich bezig moet houden met het ontwikkelen van hardware. Natuurlijk moeten ze wel samenwerken om de performance te optimaliseren (API, drivers, etc). Maar ik vind het een slechte zaak dat nVidia steeds meer met eigen "innovaties" komt.

Als er nooit een hardware-fabrikant geweest was die innovaties deed, dan hadden we uberhaupt geen 3d-accelerators gehad.
Vrijwel alle ontwikkelingen komen voort uit innovaties van hardware-fabrikanten, die later gestandaardiseerd zijn.

Daarnaast vind ik het nogal frappant dat je nVidia hierop afrekent, terwijl AMD Mantle ook presenteert als hun eigen 'innovatie', en dit is ook een proprietary standaard... Maar dat vind je juist weer lovenswaardig.

+1 darkjeric
@Scalibq • 5 juni 2015 10:51

Blijft grappig dat AMD steeds wordt afgerekend op het feit dat Mantle alleen maar werkt op GCN-kaarten. Het is by design een optimalisatie-API die specifiek voor GCN is ontwikkeld, en dan zou je dat willen draaien op andere kaarten? Tegen de tijd dat ze het openbaar wilden maken (want ze beweerden wel degelijk dat ze dat van plan waren), hadden zowel Microsoft als Kronos hun nieuwe API's aangekondigd, die Mantle verder ontwikkelen grotendeels overbodig maakte. AMD heeft nu eenmaal een beperkt R&D-budget en lijkt heel wat mankracht te stoppen in hun Zen-CPU's voor volgend jaar, dus de beslissing om Mantle te staken is niet meer dan logisch.

Maar eigenlijk wil je dan dat ze hetzelfde doen als nVidia: Eigen features als HairWorks maken die by design enkel goed werken op hun eigen kaarten (en het zelfs daar niet echt super doen) en dan als extra middelvinger naar je concurrent het mogelijk maken op hun kaarten met slechte performance, en die concurrent daar dan de schuld van geven? Zou een mooie wereld worden op die manier...

Trouwens, je blijft wel beweren dat Microsoft al lang bezig was met Windows 10 en Dx12, maar vergeet niet dat Mantle werd aangekondigd eind 2013, nog voor Windows 8.1 werd uitgebracht. Dat MS al bezig was met plannen voor latere versies is logisch, maar veel concreets zullen ze toen nog niet gehad hebben. Balmer was druk aan het plannen om Nokia over te nemen, het hele bedrijf was druk bezig een opvolger voor Balmer te zoeken en de Windows-afdeling zelf werd helemaal ondersteboven gegooid. Een vol jaar later (eind 2014) verscheen pas de 8.1 Update, en toen pas kwamen de eerste geruchten van Windows 10 en Dx12 bovendrijven.

En zelfs dan nog: Ook al verwijt je AMD dat het vooral om marketing draaide bij Mantle, dan nog hebben ze de industrie vooruitgeholpen daarmee. Voor Mantle sprak werkelijk niemand nog over low-level API's (toen Dx11 uitkwam was er bijlange na zo geen aandacht voor), maar sinds Mantle zat iedereen te wachten op info over Dx12 en Vulcan en is het meteen voorpaginanieuws als er iets bekend wordt.Op zijn minst DAT is te danken aan AMD

+1 Scalibq
@darkjeric • 5 juni 2015 11:14

Blijft grappig dat AMD steeds wordt afgerekend op het feit dat Mantle alleen maar werkt op GCN-kaarten. Het is by design een optimalisatie-API die specifiek voor GCN is ontwikkeld, en dan zou je dat willen draaien op andere kaarten?

Ja, dat is het probleem he? AMD roept dat Mantle een open standaard zou worden. Dus dan verwacht je inderdaad niet dat ze het speciaal voor GCN gaan ontwikkelen, want dat staat nogal haaks op de doelstelling.
Er zitten gewoon te veel inconsistenties tussen AMD's verhaal naar de media en hun handelen.

dus de beslissing om Mantle te staken is niet meer dan logisch.

Die kon je van tevoren al invullen, en dat heb ik dus ook al lang voordat Mantle uitkwam gezegd: https://scalibq.wordpress.com/2013/10/14/steamos-and-mantle/

The first few generations of PowerVR hardware supported the API, but the newer Kyro architecture did not, so you could no longer run any PowerVR-specific code on them, only Direct3D and OpenGL. Mantle may suffer a similar fate.

Waarom AMD er dan uberhaupt aan begonnen is, blijft een raadsel. Behalve dan als het vooral om marketing en imago draait.

Maar eigenlijk wil je dan dat ze hetzelfde doen als nVidia: Eigen features als HairWorks maken die by design enkel goed werken op hun eigen kaarten (en het zelfs daar niet echt super doen) en dan als extra middelvinger naar je concurrent het mogelijk maken op hun kaarten met slechte performance, en die concurrent daar dan de schuld van geven? Zou een mooie wereld worden op die manier...

Je zegt het nogal cru, maar ik vind wel dat concurrenten elkaar moeten uitdagen om met nieuwe en betere oplossingen te komen.

maar vergeet niet dat Mantle werd aangekondigd eind 2013

En eind 2013 kondigde Microsoft ook 'Threshold' aan, Windows 10 dus: http://www.zdnet.com/arti...windows-wave-takes-shape/

Een vol jaar later (eind 2014) verscheen pas de 8.1 Update, en toen pas kwamen de eerste geruchten van Windows 10 en Dx12 bovendrijven.

Niet dus, zie hierboven.
Eind 2013 was Windows 10 al een vrij concreet ding. Zoals je kunt lezen, was het toen ook al het plan dat deze versie op alle devices ging draaien, ook de Xb1.
Wat dus impliceert dat ze ook met een DirectX-versie komen die voor al die devices geschikt is, DX12 dus.

Voor Mantle sprak werkelijk niemand nog over low-level API's

Zeker wel, het ging toen alleen niet zo publiek als toen AMD erover begon. AMD bereikt dan ook een ander publiek. Jij zit misschien niet in de eerste groep.

+1 darkjeric
@Scalibq • 5 juni 2015 12:05

Nope, ik zit inderdaad bij de eerder mainstream Tweakers-groep, zonder echte eigen ervaring met grafisch API-programmeren. De beperkte kennis die ik heb komt van Tweakers, Anandtech en Ars Technica, en de bijbehorende fora. En vanaf vandaag: Je blog ;-)

Ook al waren de ontwikkelingen aan andere low-level API's al gaande, dan nog vind ik het gewoon slim dat AMD er zo publiekelijk mee heeft uitgepakt. Kijk naar hoeveel aandacht ze ervoor hebben gekregen. Misschien wat onterecht, maar dat kan je evengoed zeggen van elke Apple-aankondiging.

Feit blijft gewoon dat AMD op GPU-gebied hetzelfde lijkt mee te maken als rond 2006 met hun CPU's. Toen waren de Athlons veruit superieur aan de Pentium 4's, maar dat bracht ze eigenlijk niks op qua marktaandeel. Ook op de GPU-markt hebben ze enkele keren voorgelopen op nVidia (bv. de HD4xxx-reeks was echt super voor low-cost en toch high-performance en zuinigheid terwijl nVidia stuntelde met de GTX480) maar daar nooit echt voordeel van ondervonden. Terwijl als nVidia met bv. Maxwell op de markt komt (zelfde superioriteit als de Radeon HD4xxx-reeks in 2008/2009) pakken ze wel hele volksstammen marktaandeel terug. AMD krijgt gewoon de kans niet om hetzelfde aan R&D te besteden als Intel en nVidia, en die doen er natuurlijk alles aan om hun eigen implementaties af te dwingen zodat AMD verder wordt tegengehouden.

Als ik de R&D-budgetten van Intel en nVidia tegenover die van AMD bekijk, vind ik het juist bijzonder knap dat ze nog zo goed weten mee te komen eigenlijk. Als je echt een fan bent van concurrentie: Always root for the underdog

+1 Scalibq
@darkjeric • 5 juni 2015 12:18

dan nog vind ik het gewoon slim dat AMD er zo publiekelijk mee heeft uitgepakt. Kijk naar hoeveel aandacht ze ervoor hebben gekregen.

Ja, maarja, dan moet het wel goed aflopen...

Misschien wat onterecht, maar dat kan je evengoed zeggen van elke Apple-aankondiging.

Het verschil is dat Apple z'n eigen 'cocon' heeft.
AMD zit in een markt waar ze het niet alleen voor het zeggen hebben. Met Mantle hebben ze zich wel afgezet tegen Microsoft, nVidia en Intel, en in eerste instantie ook tegen Khronos.
Het signaal aan de industrie was: "Wij hebben geen zin om met jullie mee te werken, we doen alles wel zelf".

Dat kan ze nog lelijk gaan opbreken als DX12/Vulkan een iets andere koers gaan varen, en AMD niet mee kan komen met GPU-features en/of driver-support (met DX11 support is het ook al niet zo best).

Ook op de GPU-markt hebben ze enkele keren voorgelopen op nVidia (bv. de HD4xxx-reeks was echt super voor low-cost en toch high-performance en zuinigheid terwijl nVidia stuntelde met de GTX480) maar daar nooit echt voordeel van ondervonden.

Achteraf staat de GTX480 ineens in een ander licht, vind je ook niet?
GTX480 ondersteunt gewoon DX12, waar AMD's 4xxx en 5xxx-serie daar geen support voor krijgt.
En GTX480 had al gewoon een efficiente tessellator, waar nVidia nu vrolijk op doorbouwt, en nu terugbetaald krijgt voor hun investering in GTX480.

Ja, de GTX480 was erg ambitieus, en niet direct een succes. Maar achteraf heeft nVidia eigenlijk toen de slag geslagen waardoor ze er nu veel beter voor staan dan AMD.

Als je echt een fan bent van concurrentie: Always root for the underdog

Daar ben ik het niet mee eens. Dat gaat alleen op als de spelers nog enigszins op hetzelfde niveau bezig zijn.
Vooral op CPU-gebied is AMD inmiddels dermate ver achterop geraakt dat het weinig nut meer heeft om deze 'underdog' nog te gaan steunen.
Op dat moment ben je ze eigenlijk gewoon aan het belonen voor hun fouten, en daar heeft niemand wat aan.
Laat ze dan maar liever failliet gaan, en over laten nemen door een ander, die er misschien wat meer van kan maken.

+1 darkjeric
@Scalibq • 5 juni 2015 23:28

Ok, even overlopen. Dus nVidia, Apple en andere bedrijven doen investeringen die later goed uitpakken, en daar ben je positief over. Als AMD gelijkaardige gokjes en risico's doet (cfr. Mantle), hadden ze dat beter niet gedaan want het stuurt een verkeerd signaal naar de rest van de industrie en breekt ze zuur op? Ik blijf het nogal opvallend vinden dat je AMD zo bekritiseert om vaak exacte dezelfde gokjes die je bij andere bedrijven net positief beoordeelt.

Je gaat ook wel erg ver om nVidia nog te verdedigen. De GTX480 blijft een gedrocht van een kaart, die nog steeds als stofzuiger bekend staat en veel te veel stroom vreet voor de geleverde performance (zelfs tegenover heethoofden als de R9 290X of de befaamde GeForce 5900-reeks). Dat ie nu Dx12 zal ondersteunen ben je hoegenaamd ook 'vet' mee, aangezien die GPU ondertussen zo oud is dat het voor de meeste games op 1080p al niet meer voldoet. Dat AMD hun kaarten van zes jaar geleden niet meer support, vind ik trouwens niet meer dan normaal in een markt die zo snel evolueert. En dat zeg ik als iemand die nog steeds een Radeon HD4890 gebruikt, die overigens nog steeds perfect draait onder Windows 10 ook al is er geen support

Tuurlijk, AMD heeft evengoed miskleunen gehad. ATI stond nu niet echt bekend om hun driverstabiliteit (AMD ook niet), de Bulldozer-architectuur bleek eerder een stilstand te zijn en het lukt ze niet echt om developers warm te krijgen voor hun eigen implementaties, hoe 'open-source' ze die ook maken. Wil dit dan zeggen dat ze de handdoek maar in de ring moeten gooien en opgeven? Op die manier had elk bedrijf wel mogen opgeven...

Je zegt trouwens dat Apple een eigen cocon heeft, en er daarom mee wegkomt. Ook dat is weer met twee maten en gewichten werken, want wat denk je dat ELK bedrijf steeds probeert te doen? Juist ja, een eigen cocon maken. AMD probeert dit vaak wel opener te doen dan de meeste (kuch nVidia), maar heeft hier nog niet veel voordeel van ondervonden.

Kwestie van de underdog niet te onderschatten: Fiji wordt volgens mij toch wel een hele vooruitgang voor AMD ondanks de 28nm, anders had nVidia niet snel nog de GTX 980 Ti voor die introductieprijs uitgebracht. Ook de nieuwe Zen-CPU's zouden weleens verrassend uit de hoek kunnen komen, niet voor niets worden deze weer ontwikkeld onder leiding van dezelfde kerel die ook verantwoordelijk was voor de Athlon XP's die toendertijd rondjes om Intel liepen. Los daarvan is AMD op vlak van APU's nog steeds veruit de beste, en blijken ze steeds in staat die voorsprong te behouden ondanks hun miniem R&D-budget. Te ver achterop zijn ze zeker nog niet, maar de volgende jaren worden wel cruciaal

Kleine disclaimer: Mijn volgende videokaart wordt wellicht een GTX 980 Ti, dus dit post ik allemaal niet als AMD-exclusive fanboy ofzo

+1 Scalibq
@darkjeric • 5 juni 2015 23:37

Ok, even overlopen. Dus nVidia, Apple en andere bedrijven doen investeringen die later goed uitpakken, en daar ben je positief over. Als AMD gelijkaardige gokjes en risico's doet (cfr. Mantle), hadden ze dat beter niet gedaan want het stuurt een verkeerd signaal naar de rest van de industrie en breekt ze zuur op? Ik blijf het nogal opvallend vinden dat je AMD zo bekritiseert om vaak exacte dezelfde gokjes die je bij andere bedrijven net positief beoordeelt.

Je mist de nuance blijkbaar. Mantle is een API die DX11/OGL 4.4 dunnetjes overdoet.
We hebben dus al TWEE standaarden hiervoor. Waarom een derde, die niets toevoegt, en AMD-only is?
Dat soort dingen doen nVidia en Apple niet.
Apple kwam met OpenCL, omdat er nog geen open standaard voor GPGPU was.
nVidia komt met dingen als G-sync, PhysX en Cuda omdat die technologie nog helemaal niet bestaat.
Dat is nogal een verschil.
Als nVidia de vinger zou geven naar DX/OGL en met een eigen API zou komen, zou ik precies hetzelfde gezegd hebben: domme actie, gedoemd te mislukken. Hou je bij de standaarden.

Je zegt trouwens dat Apple een eigen cocon heeft, en er daarom mee wegkomt. Ook dat is weer met twee maten en gewichten werken, want wat denk je dat ELK bedrijf steeds probeert te doen? Juist ja, een eigen cocon maken.

Proberen misschien. Apple *heeft* hem. Ze leveren zowel eigen hardware als eigen software, en bepalen dus precies wat voor hardware en software er in hun 'cocon' bestaat, en hebben verder niets te maken met Microsoft, DirectX of wat dan ook.
Apple heeft dus nog meer controle dan Microsoft.
Als Apple besluit een nieuwe API te ontwikkelen, zoals Metal, dan werkt het gegarandeerd op alle Apple-hardware.

AMD daarentegen kan niet afdwingen dat Mantle gebruikt wordt door andere GPU-fabrikanten, of zelfs dat Microsoft Mantle uberhaupt toestaat op Windows.

+1 darkjeric
@Scalibq • 5 juni 2015 23:58

Want Mantle voegt niks toe op AMD-kaarten dan? Dunnetjes Dx11 overdoen is even alle benchmarks negeren die wel degelijk aantoonden dat Mantle op AMD-kaarten serieuze voordelen kon opleveren, zeker met een tragere CPU (rara, waar AMD dus extra baat heeft). Hoe is dit anders dan andere bedrijven? Apple ontwikkelde ook de Lightning-adapter op het exacte moment dat iedereen op USB overstapte.

OpenCL is ontstaan door een consortium bedrijven, waar ook AMD aan meehielp. Dus zeker niet Apple alleen. Straks ga je ook nog beweren dat bv. Webkit een pure Apple-uitvinding was?

G-Sync was iets nieuws, of toch zeker de eerste publieke implementatie van het idee, dat geef ik nVidia zeker mee. Maar PhysX was eigenlijk op de markt gekomen als software van Ageia, dat versneld werd door hun hardware 'PPU'. nVidia heeft dit bedrijf opgekocht, het aparte PPU-verhaal afgevoerd en de software enkel toegankelijk gemaakt voor GeForce-kaarten (super van ze?). Cuda was ook niet echt een nieuw idee, en was voornamelijk ook weer proprietary by design. Eigenlijk: Cuda was/is een API voor GPGPU-toepassingen die enkel werkt op GeForce-kaarten waar open alternatieven als OpenCL en DirectCompute al voor bestonden of in ontwikkeling waren. Zie je opnieuw de gelijkenis met Mantle? Low-level API, enkel AMD-kaarten, er zijn breder gedragen alternatieven. En toch is Cuda iets positiefs, en Mantle iets negatiefs?

Apple *heeft* hem omdat ze het geprobeerd hebben en erin geslaagd zijn. AMD heeft hem (nog) niet, dus blijven ze proberen. Net als elk ander bedrijf

+1 Scalibq
@darkjeric • 6 juni 2015 00:26

Want Mantle voegt niks toe op AMD-kaarten dan? Dunnetjes Dx11 overdoen is even alle benchmarks negeren die wel degelijk aantoonden dat Mantle op AMD-kaarten serieuze voordelen kon opleveren, zeker met een tragere CPU (rara, waar AMD dus extra baat heeft).

Zo spectaculair was het niet, en ook nog eens vertekend doordat de AMD DX11-driver geen goede multithreading implementeert. Zoals eerder aangetoond, nVidia's driver is gewoon twee keer zo snel onder DX11 met draw calls.

Hoe is dit anders dan andere bedrijven? Apple ontwikkelde ook de Lightning-adapter op het exacte moment dat iedereen op USB overstapte.

En Apple bouwt z'n eigen hardware.
Wat is je punt? Geschiedenislesje nodig? Tot een aantal jaren geleden draaide Apple uberhaupt niet op x86-CPUs, maar op Motorola-CPUs.
Apple is een eigen wereldje, en heeft zich nooit veel aangetrokken van wat daarbuiten gebeurt.
Dat is een unieke positie, zoals ik al zei.

OpenCL is ontstaan door een consortium bedrijven, waar ook AMD aan meehielp. Dus zeker niet Apple alleen.

Nog een geschiedenislesje nodig?
http://en.wikipedia.org/wiki/OpenCL#History

OpenCL was initially developed by Apple Inc., which holds trademark rights, and refined into an initial proposal in collaboration with technical teams at AMD, IBM, Qualcomm, Intel, and Nvidia. Apple submitted this initial proposal to the Khronos Group.

Het was dus zeker wel Apple alleen die ermee kwam.
Maar zoals gezegd, ze gingen voor een open standaard, dus gingen ze naar Khronos, en dus zitten alle IHVs dan ook meteen erbij.
Dat is dus anders dan bij Mantle. Dat bracht AMD eerst als proprietary oplossing op de markt, met een aantal games... en pas DAARNA gingen ze nog eens naar Khronos.

Maar PhysX was eigenlijk op de markt gekomen als software van Ageia, dat versneld werd door hun hardware 'PPU'. nVidia heeft dit bedrijf opgekocht, het aparte PPU-verhaal afgevoerd en de software enkel toegankelijk gemaakt voor GeForce-kaarten (super van ze?).

Zeker, maar daarmee is het nog steeds de eerste GPU-accelerated physics-library, en de enige die daadwerkelijk in games wordt toegepast tot dusver.

Cuda was ook niet echt een nieuw idee

Zo, vind je het erg als ik het hier belachelijk oneens mee ben? De GeForce 8800 was 1 van de meest revolutionaire GPUs aller tijden. Voor een groot deel is dit omdat het niet slechts een GPU is, maar dus ook Cuda mogelijk maakt.
Compleet anders dan alle GPUs die ervoor kwamen, en het heeft ATi jaren gekost om met een architectuur te komen die ook goed is in DirectCompute/OpenCL.

waar open alternatieven als OpenCL en DirectCompute al voor bestonden of in ontwikkeling waren.

Wederom een geschiedenislesje nodig:
Cuda stamt uit 2006. DirectCompute is DX11, dus 2009.
OpenCL is uit 2008.
Toen nVidia met Cuda kwam, *begon* men pas te denken aan GPGPU.
Dat was dus de trigger voor Apple: die dacht "Wacht eens even, GPGPU vinden we mooi, maar we willen niet aan nVidia hardware vastzitten. Daar moet een oplossing voor komen."
Maar grappig dat je het toch met zo'n stelligheid beweert.

Zie je opnieuw de gelijkenis met Mantle?

Nee, totaal niet dus.
En ik neem aan dat jij er na je geschiedenislesje ook wel anders over gaat denken.

Apple *heeft* hem omdat ze het geprobeerd hebben en erin geslaagd zijn.

Uhh, hoezo?
Nog een geschiedenislesje?
Apple was de eerste die een 'personal computer' op de markt bracht, zoals wij die nu kennen.
Ze zijn er vanaf het begin bij geweest. Lang voordat IBM uberhaupt begon aan de PC, die uiteindelijk leidde tot de x86/Windows-hegemonie.
Apple was er altijd al, en is altijd blijven bestaan.

AMD heeft hem (nog) niet, dus blijven ze proberen. Net als elk ander bedrijf

Vrij kansloos als je niet de hele keten beheert, zoals Apple... Complete systemen leveren, hardware en software.

+1 freaq
@Scalibq • 4 juni 2015 22:42

ik denk dat we beide wel early access hebben
en we weten beide dat delen van de xbone low level api meer "mantle achtig" waren,

maar komaan kijk naar de onderliggende veranderingen, je kan toch neit anders dan concluderen dat de gelijkenissen treffend zijn...
*en nee ik ga niet in details ik zit al op het randje van hoever ik mag gaan...

weet niet of je met mantle gewerkt hebt maar dat spul hadden wij 3-4 jaar geleden in handen ?

[Reactie gewijzigd door freaq op 4 juni 2015 22:44]

+1 Scalibq
@freaq • 4 juni 2015 22:43

ik denk dat we beide wel early access hebben

Dat denk ik niet.
Wat is je username op het forum? Dan stuur ik je een PM.

en we weten beide dat delen van de xbone low level api meer "mantle achtig" waren,

Hee... maar de Xb1 API is van Microsoft! En die was er eerder dan Mantle!
Begin je hem te snappen?

+1 freaq
@Scalibq • 4 juni 2015 22:45

ja en die API was later dan Mantle...

correctie-
die api was later bruikbaar en echt low level dan ik access had tot mantle...

[Reactie gewijzigd door freaq op 4 juni 2015 22:47]

+1 Scalibq
@freaq • 4 juni 2015 22:47

ja en die API was later dan Mantle...

Niet dus.
Sowieso had je al eerdere Xboxen met low-level APIs.

En, geen username dus? Zal je ook wel geen account hebben op het DX12-forum. Geen early access dus.

+1 darkjeric
@Scalibq • 5 juni 2015 09:59

Dat Mantle en de Xbox One API heel dicht bij elkaar liggen, kan bijna niet anders. Beide zijn specifiek aangepast aan de GCN-architectuur van AMD, want ohja, de Xbox One (en de PS4) gebruiken een GCN-GPU.

Ofwel zijn Mantle en de Xbox One-API dus heel gelijkaardig (en AMD zal Microsoft sowieso wel geholpen hebben bij de implementatie), ofwel bestaan beide bedrijven uit alleen maar idioten en hebben ze twee keer werk geleverd voor hetzelfde ding.

Wel grappig dat je zo blijft 'haten' op alles wat ATI/AMD uitbrengt, en je alles van nVidia verdedigt. Aangezien je ook zo in het wereldje lijkt te zitten, begin ik dan ook te vermoeden dat je niet geheel onpartijdig bent, en wellicht ergens 'affiliated' bent met een bedrijf dat er baat bij heeft mocht AMD in een negatief daglicht komen te staan.

+1 Scalibq
@darkjeric • 5 juni 2015 10:05

Dat Mantle en de Xbox One API heel dicht bij elkaar liggen, kan bijna niet anders. Beide zijn specifiek aangepast aan de GCN-architectuur van AMD, want ohja, de Xbox One (en de PS4) gebruiken een GCN-GPU.

Ofwel zijn Mantle en de Xbox One-API dus heel gelijkaardig (en AMD zal Microsoft sowieso wel geholpen hebben bij de implementatie), ofwel bestaan beide bedrijven uit alleen maar idioten en hebben ze twee keer werk geleverd voor hetzelfde ding.

Dus je bent het met me eens dat de low-level APIs van de XB1/PS4 er eerst waren.
Die machines werden namelijk al ergens in 2012 geleverd aan ontwikkelaars, compleet met alle ontwikkeltools, dus een complete API (toen de consoles gelanceerd werden, waren er al kant-en-klare games die gebruik maakten van die API).
Mantle was toen nog lang niet af.

Wel grappig dat je zo blijft 'haten' op alles wat ATI/AMD uitbrengt, en je alles van nVidia verdedigt.

Als jij het zo ziet, zegt dat meer over jou dan over mij.
Ik zou zeggen, lees eens wat van m'n blogs: https://scalibq.wordpress...ldskoolretro-programming/
Komt niet heel veel nVidia-hardware in voor, toch?
Misschien ben ik wel... *shock*... onpartijdig! En gewoon objectief kritisch!

[Reactie gewijzigd door Scalibq op 5 juni 2015 10:08]

+1 darkjeric
@Scalibq • 5 juni 2015 10:21

Dat de Xbox One & PS4-API's er eerst waren klopt inderdaad, maar ik vermoed dat AMD daar voor een groot stuk bij geholpen zal hebben aangezien zij de volledige hardware voor beide consoles maken.

Ik beweer ook zeker niet dat AMD Mantle de eerste low-level API is, want ook Nintendo doet dat al jaren met al hun consoles, en ook de recentere consoles als PS3 en Xbox 360 hadden een geheel eigen geoptimaliseerde API (kijk maar eens wat ze op het eind nog uit die bakken konden sleuren).

Wat ik wel beweer (en geloof, niet meer dan dat) is dat AMD de eerste was om low-level API's terug naar de PC te willen brengen, terwijl de rest van de industrie al jaren de omgekeerde beweging aan het maken was. Ik vermoed dat ze dat eigenlijk ook niet zelfstandig wilden doen, maar dat gewoon geen enkele andere speler er de voordelen van inzag. En omdat ze op een paar vlakken wel degelijk een hoop winst blijkten te behalen met Mantle (en er vooral heel veel persaandacht mee bereikten), zijn ook de andere grootmachten zoals Kronos en Microsoft overstag gegaan en terug gaan focussen op low-level. Dus dat hebben we (volgens mijn eigen bescheiden mening) aan AMD te danken.

+1 Scalibq
@darkjeric • 5 juni 2015 10:32

Dat de Xbox One & PS4-API's er eerst waren klopt inderdaad, maar ik vermoed dat AMD daar voor een groot stuk bij geholpen zal hebben aangezien zij de volledige hardware voor beide consoles maken.

Dat zal vies tegenvallen.
AMD heeft helemaal niet zo'n grote software-afdeling, en heeft weinig ervaring met het ontwikkelen van eigen APIs.
Mantle konden ze ook niet alleen af. Daar hadden ze DICE voor nodig.
Dus stel je er maar niet zo heel veel van voor. Het grootste deel is door Microsoft en Sony gedaan.

Wat ik wel beweer (en geloof, niet meer dan dat) is dat AMD de eerste was om low-level API's terug naar de PC te willen brengen, terwijl de rest van de industrie al jaren de omgekeerde beweging aan het maken was.

Dat lijkt mij niet, aangezien MS dit al in het drivermodel van Windows 10 heeft opgenomen.

(en er vooral heel veel persaandacht mee bereikten)

Dit zal de voornaamste reden zijn geweest. Een groot marketing-offensief.
Helaas gaat dit straks wel in hun gezicht ontploffen, als blijkt dat ze geen goede DX12-drivers en GPUs kunnen leveren op het moment dat Windows 10 en DX12 uitkomen.

Dan gaat men denken van: "Huh? Jullie waren toch zo van de low-level APIs, en van het pushen van de graphics-industrie? Leuk, dat Mantle, maar dat ging dus ten koste van dingen die belangrijk zijn."

zijn ook de andere grootmachten zoals Kronos en Microsoft overstag gegaan en terug gaan focussen op low-level. Dus dat hebben we (volgens mijn eigen bescheiden mening) aan AMD te danken.

Microsoft was al 'overstag', maar het probleem is dat MS ook een OS moet ontwikkelen, en moet zorgen dat alle fabrikanten het eens zijn. Niet alleen AMD en nVidia, maar ook Intel, en niet te vergeten de GPU-fabrikanten voor smartphones en tablets, dus ook ARM, Qualcomm, Imagination Tech etc.
Dat duurt langer, en daarom kon AMD dus de ideeen stelen en een paar maanden eerder op de markt krijgen, maar dan alleen voor een paar AMD GPUs.

Khronos is geen grootmacht, en alle eerdere pogingen om OpenGL grondig te herzien, zijn mislukt. Dus zij volgen normaal gesproken DX12 maar een beetje. Zij hebben nu wel voordeel van Mantle.
Maar zoals ik al vaker zei: het is frappant dat AMD niet meteen met Khronos samenwerkte, en meteen Vulkan ontwikkelde. Mantle is en blijft proprietary, en dat was niet wat AMD beloofde.

TweakingRens
@Scalibq • 3 juni 2015 19:39

Ik kan me iets erinneren dat AMD had toegezegd om alles van Mantle opensource te maken zodra het klaar was. TressFX is op dit moment in ieder geval wel vrij te gebruiken door Nvidia, ze doen het alleen niet omdat ze per sé een eigen (closed) standaard willen hebben.

0 Scalibq
@TweakingRens • 3 juni 2015 23:02

TressFX is middleware. Het is niet aan nVidia om TressFX te gebruiken, maar aan game-ontwikkelaars.
nVidia levert met Hairworks een alternatief. Dat heet concurrentie.

Countess

@Scalibq • 3 juni 2015 23:13

Dat heet concurrentie.

als dat concurrentie is dan liever zonder. dat zou voor klanten van beide namelijk beter zijn geweest.

0 Scalibq
@Countess • 3 juni 2015 23:22

Waarom? Nu hebben we Hairworks, die weer een betere rendermethode toepast dan TressFX.
En dat moet AMD dus weer beantwoorden door TressFX weer te verbeteren etc etc.
Zo werkt concurrentie.

0 SG

@Scalibq • 4 juni 2015 11:05

Nee. Dit is geen concurentie
Concurrentie berust op vrije keuze. Hier is middleware gekoppeld aan hardware.

Zoals havok vs Physx is concurrentie op development middleware market.
Voor ons gamers is het geen concurrentie.
Havok het mag van intel geen GPGPU gebruiken killen van havokFX door intel overname.
PhysX gpgpu is nV gpu only.
Gekoppeld aan.

Will de hardware pushen dan beperkt havok je tot cpu. Physx ben je beperkt tot CPU omdat mainstream target blijft. Gpgpu physx optie is beperkt tot effect physics.

Nee PC games zouden iets hogere gkaart eisen hebben met elke triple A game dosis havokFX waar ook gameplay op gpu kan.

Nee dat PU bakkers middleware bezitten is hele slechte zaak.

+1 Scalibq
@SG • 4 juni 2015 11:48

Nee. Dit is geen concurentie
Concurrentie berust op vrije keuze. Hier is middleware gekoppeld aan hardware.

Hoezo gekoppeld aan hardware? Hairworks werkt ook op AMD/Intel.
En dan nog. Middleware koppelen aan hardware is nog steeds concurreren.

+1 Pb Pomper
@Scalibq • 5 juni 2015 10:20

Hoezo gekoppeld aan hardware? Hairworks werkt ook op AMD/Intel.
En dan nog. Middleware koppelen aan hardware is nog steeds concurreren.

Haha. Met 2 FPS misschien ja. Maarja, dat komt nVidia niet slecht uit natuurlijk.

+1 Scalibq
@Pb Pomper • 5 juni 2015 10:23

Haha. Met 2 FPS misschien ja. Maarja, dat komt nVidia niet slecht uit natuurlijk.

Nee, als AMD een performance-probleem heeft in hun hardware, is het tijd om hun GPU-architectuur eens te updaten.
Hairworks doet niets bijzonders, gewoon 100% standaard DX11-code.
Iedereen die een goede DX11-GPU ontwikkelt, kan dat goed draaien.

Werelds

@simplicidad • 3 juni 2015 14:59

Ze zullen uiteindelijk wel moeten. Hun mobiele implementatie laat zien dat wat zij met G-Sync doen ook gewoon hetzelfde is als AMD vorig jaar liet zien en waar Adaptive Sync op is gebouwd. Het enige dat ze nu nog hebben is hun scaler die in staat is RTC iets effectiever toe te passen; en laat dat nu ook langzaam aan opgelost worden (zie mijn reactie op kiang hierboven; BenQ heeft het aan de praat).

Musical-Memoirs

@Werelds • 3 juni 2015 14:14

Nvidia is volgens mij overtuigd dat hun oplossing beter functioneert en hopen dat men de meerprijs voor over hebben. Als ze de open oplossing van AMD erbij/over nemen dan zal de meerwaarde van een Gsync module snel verdwijnen. Ook zal het slecht voor hun reputatie zijn als ze van Gsync af stappen. Ze kunnen dus beter hun poot stijf houden op de hoop dat G-sync volledig een plek in de markt heeft gekregen, maar vind het wel jammer dat dat nodig zal zijn en hoop dat ze ooit beide hebben.

Ik zelf het idee dat de oplossing van Nvidia ook beter functioneert naar alles dat ik over beide gelezen heb. Maar als ze beide gaan ondersteunen (wat ik op lang termijn hoop) zal ik waarschijnlijk toch voor de lager geprijsde FreeSync gaan. Voor nu wacht ik nog even voor ik een nieuw scherm koop.

[Reactie gewijzigd door Musical-Memoirs op 3 juni 2015 14:19]

holhuizen
@Musical-Memoirs • 3 juni 2015 14:28

Even afgezien van de prijs, wat is precies het verschil ? Dit doet me een beetje denken aan , het is duurder dus het zal wel beter werken ?

Musical-Memoirs

@holhuizen • 3 juni 2015 14:38

De oplossing van AMD is een 'dom systeem', het weet niet hoe het beeldscherm werkt en veranderd alleen maar framerate. Wat je voor problemen kan hebben is flikkering in het beeld en incorrecte kleur weergave. Gsync zorgt voor juiste kleurcorrecties. Bij extreem lage framerates verdubbelt of viervoudigd de Gsync module de framerate met het tonen van het zelfde beeld om te voorkomen dat flikkering zal ontstaat.

edit:
Waarom de minnetjes, omdat ik het dom noem? Ik noem het namelijk een 'dom systeem' omdat het nog geen rekening houd met hardware limieten van het beeldscherm. Tussen de aanhalingstekens omdat het nog steeds beter is dan zonder Freesync.

[Reactie gewijzigd door Musical-Memoirs op 3 juni 2015 15:40]

holhuizen
@Musical-Memoirs • 3 juni 2015 14:47

Ten eerste komt een standpunt wat beter over als je een bron heb.

Je kunt het onbewerkt laten van het beeld "dom" noemen maar ik zie er ook voordelen aan. Het is namelijk vast fijn dat er extra frame's worden toegevoegd ( dus bijv 2 of 3 x het zelfde frame achter elkaar ) hierdoor krijg je een extra kunstmatige latency, want het zelfde frame word dus meerde keren achter elkaar weergegeven, waardoor je dus een paar milliseconde het zelfde ziet ipv wat er in de game gebeurt op dat moment.

En dat van dat kleur correctie, dat lijkt me niet nodig omdat de displaysport de frequentie regelt en volgens mij geen afbraak doet aan de kleur van het geproduceerde beeld uit de GPU ? maar goed al Nvidia extra mooie kleur weet weer te geven zonder extra latency toe te voegen zou dat mooi zijn.

+1 supersnathan94
@holhuizen • 3 juni 2015 14:54

ipv wat er in de game gebeurt op dat moment

.

Op het moment dat je monitor 2 à 3x zoveel extra frames bij moet kopieren doe je toch al iets fout en mis je ook zonder G-sync de in-game action. Dit betekent namelijk dat je bij een standaard monitor (60Hz) tussen de 20 en 30 FPS haalt. Dit is zonder G-sync nog steeds veelste weinig om shooters echt goed te kunnen spelen (50-60+ fps)

[Reactie gewijzigd door supersnathan94 op 3 juni 2015 14:55]

+1 gryz
@supersnathan94 • 3 juni 2015 15:30

Dit is zonder G-sync nog steeds veelste weinig om shooters echt goed te kunnen spelen (50-60+ fps)

Het gaat er niet om om het perfect te maken.
Dat zou pas zijn bij 240fps @ 240Hz of zo.

Het gaat er om dat het negatieve effect (stotter) zo veel mogelijk verminderd wordt. Het wordt niet perfect. Het wordt minder hinderlijk.

Bovendien spelen we niet allemaal shooters. En toch willen we allemaal zo'n vloeiend mogelijk beeld. Als ik mijn RPG of adventure game speel, dan wil ik maximale eyecandy. Als die er voor zorgt dat ik 30-40 fps haal (met soms dips onder de 30), dan is het mooi dat G-Sync dat er vloeiender uit laat zien dan zonder G-Sync. Voor jou misschien niet acceptabel. Maar voor mij wel.

+1 supersnathan94
@gryz • 3 juni 2015 16:27

Het gaat er om dat het negatieve effect (stotter) zo veel mogelijk verminderd wordt. Het wordt niet perfect. Het wordt minder hinderlijk.

stutter is een probleem wat je absoluut niet kan verhelpen door 2 of meer keer hetzelfde frame te tonen binnen je bereik. Dit komt puur doordat je niet genoeg beeld informatie aanvoert. TV's hebben daar een trucje voor waardoor de tussenliggende frames enigszins berekent kunnen worden, maar dit brengt wel de nodige vertraging in het materiaal met zich mee. Nu is dit bij een film of serie geen probleem daar de informatie stabiel is en al van tevoren bekend. 2 seconden vertraging merk je dan absoluut niet aangezien alles 2 seconden vertraagt wordt (sluit maar eens een analoge tv aan naast je digitale het decoderen van de stream vereist ook al enkele seconden).

Met realtime informatie kan dit gewoon niet aangezien je de rekenkracht al niet hebt om het in eerste instantie gelijk goed te doen.

Dit is dus niet inherent verbonden aan G-sync/FreeSync. Je monitor doet dit namelijk zelf ook al. Dacht je dat een 120Hz TV ook meteen 120Hz beeldinformatie krijgt? nee dat is maar 60Hz hier in Nederland. Stutter wordt niet minder als je hetzelfde frame nogmaals laat zien. Dit gebeurt namelijk nu ook al als je invoer 1/2 de verversingssnelheid van je beeldscherm is. Waar G-sync voor zorgt, is dat er geen tearing optreed doordat je rare inputfrequenties hebt (zeg 55 FPS met een 60Hz beeldscherm. Door het scherm dan ook maar op 55Hz te laten werken heb je een vloeiender beeld doordat je dus niet om de 11 frames ineens een 50% frame 12 50% frame 13 hebt. Dit is namelijk het probleem waar we al sinds CRT mee zitten.

Dat is de kracht van deze techniek aangezien je nooit continue precies op de verversings frequentie van je beeldscherm zit. Met normaal gebruik zal minimaal 8 -10% van je frames tearing bevatten met freeSync/Gsync is dit vrijwel 0 (althans dat is het idee).

holhuizen
@supersnathan94 • 3 juni 2015 15:00

ja natuurlijk, daarom zie dus de de meerwaarde van die techniek niet in. want op het moment dat je het nodig hebt zorgt het voor meer latency. En wanneer je toch al genoeg fps hebt om de game goed te spelen heb je de techniek niet nodig. Waarom zou je dan meer moeite stoppen om het te implementeren .

Musical-Memoirs

@holhuizen • 3 juni 2015 15:34

Nee hier begrijp je het verkeerd, want er komt geen latency bij. 2x dezelfde frame op dubbele framerate geeft net zo veel zichtbare frames in de zelfde tijd weer zonder vertraging.

Maar ja, als je framerate zo hard duikelt is games spelen nog steeds niet fijn, dan is een nieuwe videokaart veel verstandiger dan een nieuw beeldscherm met Freesync/Gsync. Maar je kan wel prettiger spelen op lage framerates als er geen stuttering/delay/tearing is, wat je anders heel extreem zou hebben. Sommige games hebben enkele hele korte momenten die zwaar zijn en je framerate zwaar omlaag gooit, die korte momenten zijn dan beter te hebben.

Musical-Memoirs

@holhuizen • 3 juni 2015 15:09

2 frames van dubbele snelheid past binnen exact de zelfde tijd als 1x de originele framerate die onder de grens van flikkeren zit.
Voorbeeld wanneer een beeldscherm bijvoorbeeld flikkert bij 24 fps
framerate van de GPU - framerate die het beeldscherm weergeeft.
60 - 60
40 - 40
27 - 27
24 - 48 (2x het zelfde beeld dat in de zelfde tijd past van een framerate van 24)
20 - 40 (2x)
11 - 33 (3x het zelfde beeld dat in de zelfde tijd past van een framerate van 11)

Door een verdubbeling kan je de werkelijke beeld verversing boven het grensgebied van flikkeren houden zonder de zichtbare beeldverversing aan te passen. De verversing naar een daadwerkelijk ander beeld gebeurd net zo snel dus heeft geen extra latency. Er wordt geen frame geskipped, die frame is er namelijk gewoon niet want de framerate is te laag door gebrek aan de GPU kant, de volledige reden waarom FreeSync en Gsync überhaupt bestaan.

Zoek later nog wel even bronnen op, maar een andere tweaker heeft nog mooie uitleg over de kleurweergave: kiang in 'nieuws: AMD demonstreert FreeSync-over-hdmi'

[Reactie gewijzigd door Musical-Memoirs op 3 juni 2015 15:11]

+1 supersnathan94
@Musical-Memoirs • 3 juni 2015 16:32

Dit is dus precies wat een normaal beeldscherm ook al doet alleen houd dit beeldscherm dan geen rekening met komende informatie. bij het opbouwen van je beeld kan het dan dus voorkomen dat de monitor een nieuw frame binnenkrijgt terwijl hij net de eerste helft van het oude frame heeft verwerkt. Dit fenomeen staat bekend als tearing. G-sync/FreeSync is dus niet tegen stutting, maar tegen tearing. Stutting is simpelweg het feit dat een persoon beelden niet als vloeiend ervaart (dus 11 Hz opwaarderen naar 33 Hz heeft dus 0 zin aangezien je dit nog steeds merkt (je maakt alleen de frametime langer)). Het daadwerkelijk zichtbare effect wat G-sync/FreeSync geeft is dat je dus gen tearing meer hebt.

Weapon S
@supersnathan94 • 4 juni 2015 10:24

Preciezer gezegd: G-sync zorgt ervoor dat je niet hoeft te kiezen tussen tear of stutter.

Tearing kan je ook verhelpen met (correcte) v-sync. Dat zorgt er echter voor dat je een soort telecine kan krijgen: de framerate die wordt geproduceerd door de GPU zou net niet deelbaar kunnen zijn door de schermfrequentie (bv. 11FPS:60Hz). Als je in zo'n geval kiest voor v-sync, heb je geen tearing; Maar dan heb je wel stuttering, omdat soms een beeld wordt gegenereerd, voordat het beeldscherm klaar is, en soms een beeld wordt gegenereerd terwijl het beeldscherm al een refresh heeft uitgevoerd.

+1 SG

@Musical-Memoirs • 4 juni 2015 10:52

Nee het is niet dom .dat Nv market het naar mytische hoogtes. Alsof de algehele scaler industrie en monitor firmware devisies te dom zijn.

Die industrie past al langer een variant toe in laptops.
Dus wie is dom? Het maakt nV ook niet slimmer dan die industrie. De slimheid daar is bij freesync de scalers van uit hun industrie. Zij kunnen al die features ook implementeren in productie scaler. Zij hebben ook firmware afdeling die al langer allerlei input verwerking en paneel aansturing ontwikkelen.

Maar in die tak krijg je dus ook instap freesync

+1 geert1
@Luukwa • 3 juni 2015 13:43

Nvidia heeft al een eigen versie van deze techniek, genaamd G-Sync. Dit gebruikt wel een hardware-onderdeel in de monitor, en werkt dus niet met bestaande monitoren.

Ik ben wel benieuwd of er veel verschil is tussen FreeSync en G-Sync, wat betreft het effectief tegengaan van tearing. Iemand die dat weet?

Ik hoop dat deze technieken de komende jaren gemeengoed gaan worden, want het model van een vaste monitor-refresh-rate is eigenlijk best achterhaald. Gelukkig kan een 144Hz-monitor ook al enorm helpen in het minder zichtbaar maken van tearing, als alternatief.

[Reactie gewijzigd door geert1 op 3 juni 2015 13:46]

Luukwa
@geert1 • 3 juni 2015 13:46

Weet wel dat GSYNC bestaat, ik wil geen extra module kopen of een nieuwe monitor.
Het is trouwens gebleken dat dit ook helemaal niet nodig is.

kiang

@Luukwa • 3 juni 2015 14:11

Nou, ik ben geen fan van Gsync omdat het closed is ipv een open standaard, maar 'niet nodig' is wat kort door de bocht. Er zijn namelijk wat voordelen die G-sync heeft tov freesync, en waarvoor je monitor een extra stuk hardware nodig heeft (of iig en wat complexere display driver dan je monitor nu heeft).

G-Sync doet namelijk aan over/underdrive correction (ze noemen het zelf variable overdrive)om kleuren correct weer te geven, ook met variabele refresh rate, iets dat freesync niet doet, waardoor er ghosting kan optreden, en kleuren er wat vervormd gaan uitzien. Dat is een rechtstreeks gevolg van het toepassen van een variabele refresh rate: de monitor weet niet meer hoe lang het huidige frame wordt, en dus kan over en underdrive niet meer correct worden ingeschat , wat inaccurate kleuren en ghosting oplevert.

Het kern van dit probleem is dat pixels niet meteen de 'juiste' kleur weergeven: als een bepaald signaal naar een pixel wordt gestuurd, veranderd die gradueel in de juiste kleur. Op het laagste niveau: als een pixel een roodwaarde van 100 moet weergeven, wordt er bvb 0.1mV naar de pixel gestuurd. Dit is een analoog, continu gebeuren.
Echter, dit graduele proces kan relatief lang duren, zeker als je op 144Hz = 6.9ms/frame werkt: als het al 4ms duurt eer je pixel de juiste kleur behaalt, wordt dus de jusite kleur minder lang weergegeven dan de graduele overgangskleur. Wat vele monitoren met hogere refresh rate dus doen, is over en underdrive, om dit proces te versnellen. Simpel uitgelegd hoe dit werkt:

Overdrive: stel een pixel is helemaal zwart en moet veranderen naar een roodwaarde van 100, dan gaat de monitor even een voltage van bvb 0.2mV op de rode subpixel zetten, wat de verandering sneller doet gebeuren, om daarna het voltage weer op 0.1mV te zetten om de correcte roodwaarde van 100 aan te houden.

Omgekeerd is er underdrive: stel een pixel heeft al een roodwaarde van 200 en meot naar 100, dan gaat het voltage even op 0, wat de roodwaarde sneller doet dalen, en na heel even wordt het voltage weer opgetrokken naar 0.1 mV, om de roodwaarde van 100 aan te houden.

Duurdere monitoren met hoge refresh rate en een groot kleurbereik passen over- en underdrive toe in hun display controller.

Echter, de bestaande algoritmen werken niet meer helemaal correct wanneer je niet meer weet hoe lang een frame wordt weergegeven: wat als er een nieuw frame moet worden weergegeven terwijl de over of underdrive nog niet is afgerond en de kleurwaarde dus nog niet gestabiliseerd is? Het grootste heikel punt daaraan is dat, gezien de kleurwaarde nog niet stabiel is, de monitor niet weet welke kleurwaarde de pixel effectief had, en dus voor het volgende frame zijn over en underdrive ook niet correct kan inschatten.

Wat de Gsync module onder meer doet, is een predictief model implementeren om de frame timing van het huidige frame in te schatten, en adh daarvan heeft nVidia ook weer een eigen over/underdrive algoritme gemaakt. Dat soort modules, gezien ze over/underdrive gaan modelleren, ga je dus ook nooit los voor eender welke monitor kunnen kopen (oversteer/underdrive parameters zijn specifiek per paneel).

Nu, is dit allemaal nodig? Hangt er vanaf: wil je erg accurate kleuren en minder ghosting? De ene wel, de ander niet. Persoonlijk heb ik gewoon een ouderwetse 60Hz monitor zonder free/Gsync en ik ben er dolgelukkig mee

Maar er is dus wel degelijk een verschil tussen Gsync en Freesync, en er is een goede reden om een dedicated gsync controller te hebben in je scherm

EDIT: bron: een basisoverzicht kan je ook lezen bij anandtech: http://www.anandtech.com/...dia-launches-mobile-gsync
Hier wordt ook vermeld waarom de aparte module bij laptops niet nodig is: de functionaliteit zit verwerkt in de aansluiting naar het scherm (dank @werelds), iets dat kan bij laptops waar GPU en laptop vast aan elkaar zitten. Bij een desktop of losse GPU kan dit niet, omdat je zomaar een ander scherm kan aansluiten, waarvoor de over/udnerdrive parameters niet meer zullen kloppen.

[Reactie gewijzigd door kiang op 3 juni 2015 16:17]

Werelds

@kiang • 3 juni 2015 14:57

Mooie post, maar je maakt wel enkele kleine foutjes.

Het gebrek aan RTC ligt niet aan FreeSync (technisch gezien moet je het eigenlijk over Adaptive Sync hebben

) - het is bij AS aan de monitor/scaler fabrikant om dit op te lossen. BenQ's XL2730Z krijgt nu een firmware fix waardoor AMA (hun RTC variant) wel werkt. Adaptive Sync is slechts een specificatie. FreeSync is AMD's GPU implementatie daarvan. G-Sync slaat op het protocol, de GPU implementatie én de monitor implementatie.

Bij mobiel G-Sync zit het ook niet in de GPU verwerkt, maar in de aansluiting naar het scherm - net als bij externe VRR monitors. In laptops gebruikt men tegenwoordig meestal embedded DisplayPort, dat zo'n beetje alle elementen waar Adaptive Sync en G-Sync uit bestaan bevat. AMD's demo vorig jaar was ook gebouwd bovenop eDP. Daarnaast moeten laptop fabrikanten alsnog met Nvidia samenwerken om RTC aan de praat te krijgen, net zoals dat het geval op de desktop is. Er zit eigenlijk geen enkel verschil tussen de laptop implementatie en de "desktop" implementatie, behalve dan dat in laptops de variabele timing toevallig in eDP zit.

kiang

@Werelds • 3 juni 2015 15:38

Helder, dank voor de verduidelijking!

Ayrell
@kiang • 3 juni 2015 14:40

Mooie post, maar volgens mij ging het in Luukwa's post niet zozeer over of Gsync zelf nodig/nuttig is, maar eerder over het feit dat er onlangs ontdekt werd in een driver dat Gsync zou kunnen werken zonder de hardware in de monitor.

+1 gryz
@Ayrell • 3 juni 2015 15:26

Gsync zou kunnen werken zonder de hardware in de monitor.

G-Sync monitoren hebben een G-Sync module. Dat is een stukje hardware (een speciale chip) die een ander stukje hardware in monitoren vervangt (de zgn. scaler). Wat doet die G-Sync module.

1) Die zorgt dat GPU en monitor frames kunnen uitwisselen met een variable refresh-rate. Ik zou zelf dat woord refresh-rate weglaten. Want er is geen rate meer. Frames worden verstuurd en getoond zodra ze klaar zijn, en niet meer in een vaste frequentie. Om dit te kunnen doen moest nVidia gebruik maken van een weinig gebruikte feature van de DP1.2a protocol. Die feature is nog iets aangepast in DP1.2a. (En heet nu Display Port Adaptive Sync (DPAS).

Is dat voldoende ? AMD dacht van wel. Die heeft FreeSync ontwikkeld. Wat eigenlijk enkel en allleen gebruikt maar van het feit dat je frames niet meer met vaste regelmaat hoeft te verzenden.

Nu blijkt dat het toch niet zo simpel is.
nVidia heeft bij de introductie van G-Sync direct al laten doorschemeren dat de G-Sync module nog een paar extra dingetjes doet. Maar ze hebben nooit gezegd precies wat allemaal.

2) Een van de dingen die je krijgt met G-Sync is ULMB. Ultra-Low Motion Blur. Ten minste als je monitor 100Hz, 120Hz of 144Hz kan doen. (Dat is niet het geval bij 4k-monitoren met G-Sync).

3) Het begint nu door te dringen dat je met G-Sync en FreeSync ook iets met de kleuren moet doen. Zeker als het scherm "overdrive" doet. Zie post elders in dit topic.

4) Wat doe je als je frames sneller of langzamer binnenkomen dan je minimum of maximum pixel-hold time ? Met andere woorden, wat doe je als je fps onder de 30 fps of boven de 144 fps komt ? nVidia heeft daar beter over nagedacht. Als fps onder de 30 komt, blijft het werken. 30 fps is nooit echt lekker, maar er komt geen extra stotter bij G-Sync. Bij FreeSync merk je er wel wat van, zelfs als je al in de buurt van de 30 fps komt (<40fps).
Bij hoger dan 144Hz had AMD weer beter nagedacht. Daar kun je kiezen tussen vsync on/off gedrag als je over de 144Hz gaat. Daar had nVidia weer niet aan gedacht.

TL;DR.
Een hoop mensen denken G-Sync/FreeSync enkel en alleen Display Port Adaptive Sync is. Dat is niet waar. Er komt meer bij kijken.

Werelds

@gryz • 3 juni 2015 15:51

Voor #2 moet je wel onthouden dat de twee elkaar uitsluiten. Of je draait op 100/120/144 Hz met strobing (ULMB) of je draait met variabele refresh rate. Je kunt (nog) niet strobing met een variabele refresh rate krijgen.

Voor #4 is het zelfs nog iets genuanceerder dan jij uit legt; onder de 30 Hz blijft G-Sync niet zomaar werken. G-Sync gaat dan frames dupliceren om aan 30 Hz te komen. Als je dus op 15 FPS draait, krijg je elk frame twee keer te zien. De daadwerkelijke refresh rate is echter nog steeds 30 Hz, terwijl je met 40 FPS ook daadwerkelijke op 40 Hz draait. Het is een klein maar wezenlijk verschil. Ook dat is iets dat monitor/scaler fabrikanten gewoon in hun scalers in kunnen bouwen.

Overigens is de ondergrens bij G-Sync ook niet per definitie 30 Hz. Net als bij Adaptive Sync ligt dat aan het panel. Zie https://www.youtube.com/watch?v=VkrJU5d2RfA (PC Perspective's analyse van FreeSync en G-Sync). Die Acer XB270HU is niet in staat om onder de 37 Hz te gaan. Op 36 FPS draait het panel op 72 Hz

+1 gryz
@Werelds • 3 juni 2015 16:05

Je hebt helemaal gelijk dat het allemaal iets complexer is dan ik beschrijf. Het is hier Tweakers. En deze thread is morgen weer vergeten.

Ook dat is iets dat monitor/scaler fabrikanten gewoon in hun scalers in kunnen bouwen.

En dit klopt dus niet.
Iets wat mensen vergeten, is dat het *TIJD* kost om een frame van de GPU naar de monitor te versturen. DP/HDMI/DVI heeft tenslotte beperkte bandbreedte. Als je 1440p draait, duurt het ongeveer 6 milliseconden om een frame te versturen (eerste bit tot laatste bit). Als de GPU dus besluit om een frame dubbel te vertonen, dan moet de GPU die twee keer verzenden. En als je een frame dubbel aan het verzenden bent, en de volgende is klaar, dan moet die wachten.

De G-Sync module heeft RAM. Daar kun je ieder frame die je binnenkrijgt in opslaan. En de monitor kan dan het laatste frame dubbel laten zien. Zonder dat er data over de kabel gaat. De GPU is dan vrij om een nieuwe frame te verzenden direct als die binnenkomt. Dat kan niet als je geen RAM in je monitor hebt.

Dus ja, andere scalers zouden hetzelfde kunnen doen als G-Sync. Maar dan hebben ze ook extra geheugen nodig. En dat kost geld. En de scalers worden gecompliceerder. En duurder. En dan worden FreeSync monitoren ook duurder.

Die Acer XB270HU is niet in staat om onder de 37 Hz te gaan. Op 36 FPS draait het panel op 72 Hz

We moeten het hele concept van "rate" los laten. Er is geen rate meer. Enkel frame interval tijden.

Heb je een URL waar iemand die 37Hz op de XB270HU heeft getest ?

Werelds

@gryz • 3 juni 2015 16:48

Die URL heb ik, staat ook gewoon in mijn reactie hierboven: https://www.youtube.com/watch?v=VkrJU5d2RfA

Rond 8:30 gaan ze van 37 FPS naar 36 FPS en zie je dat er ineens dubbel zo veel frames worden getoond. Of je dat nu frame interval of rate wil noemen, feit is dat op 36 FPS het panel 72 keer per seconde ververst. Dat is op dat moment dus een refresh rate van 72 Hz of een frame interval van ~13.9ms in plaats van 36 Hz / ~27.8ms

En dat scalers dan geheugen moeten hebben klopt; maar de duurdere scalers hebben dat al. Met name de fabrikanten die de betere monitors produceren hebben eigen scalers waar sowieso al geheugen op zit. Dat neemt allemaal niet weg dat het wel kán en dat zit er bij de betere fabrikanten ook echt wel in.

+1 gryz
@Werelds • 3 juni 2015 17:35

De monitor die ze daar gebruiken is niet de XB270HU.

Duurdere scalers .... Ja, alles is mogelijk. Maar het kost meer geld. Het argument van de AMD-fanboys is altijd dat AMD alles gratis doet, en dat nVidia geld vraagt voor iets wat niet nodig is. En dat klopt dus niet. Speciale scalers in FreeSync monitoren zullen ook extra geld kosten. Als je (extra) RAM in je monitor doet, kost dat ook extra geld.

Werelds

@gryz • 3 juni 2015 17:48

Excuseer, de video is de Swift, maar PCPer heeft zowel de Swift als de XB270HU getest en ze doen allebei precies hetzelfde. Hier is trouwens het artikel dat bij de video hoort: http://www.pcper.com/revi...c-How-Technologies-Differ

Comment van Ryan:

March 29, 2015 | 02:29 PM - Posted by Ryan Shrout
We actually tested both and both behaved the same, moving into the frame doubling windows at the same points.

En tuurlijk kost het meer geld; die feature is echter iets dat de scaler fabrikanten ook graag gaan verkopen (merk je aan de snelle adoptie van Adaptive Sync) en dan komt het neer op de marge die ze daar voor willen hebben. Ik kan je verzekeren dat Nvidia een heel stuk meer voor hun ondermaatse scaler vraagt. De prijs is inmiddels gezakt, maar pakweg 4 maanden geleden was dat nog maar liefst $100. En afgezien van VRR+RTC, is het verder een heel matig apparaat waar de betere fabrikanten niets van moeten weten. Dell, Eizo of zelfs LG en Samsung zijn allemaal met AS aan de slag gegaan.

kiang

@Ayrell • 3 juni 2015 14:46

Zie mn edit: het kan inderdaad vanuit de GPU, net zoals nu in laptops gebeurt, maar dan heb je wel de correcte over/underdrive parameters nodig voor de monitor die je aansluit. Hoe haalbaar dat is weet ik niet (nVidia verzamelt parameters? je voert ze zelf in na ze te krijgen van je monitor fabrikant? je kunt zelf gaan kalibreren met eigen kalibratiehardware?)

catfish
@kiang • 3 juni 2015 15:15

ook op laptops kan je een extern scherm aansluiten, maar het lijkt mij op zich aannemelijk dat nVidia met bepaalde merken een overeenkomst sluit en dan de parameters van specifieke schermen opneemt in de drivers
zo zou het systeem goedkoper kunnen (wegens geen extra module in het scherm)
maar dat zou betekenen dat ActiveSync dit misschien ook kan op termijn

+1 Master_duck
@kiang • 3 juni 2015 14:55

geld alleen als je op of boven de spec uitkomt van het paneel. Daarom maken ze beeld verbeterings software om de problemen weg te moffelen en daar flinke prijzen voor te vragen. vaak zit er de zelfde panneel in een monitor/TV maar de software in de monitor en vooral bij TV's maakt dat het dan duurder is. wat weer kan verklaren dat duurdere TV's en monitoren vaak wel de hoogste input lag heeft.

60hz = ~ 16ms
120hz = ~ 8ms
ga mij niet zeggen dat een scherm problemen krijgt met ghosting en kleuren omdat de fps naar 30 zakt ipv 60fps.

als deze nou van 120fps naar 240fps gaat krijg je wel ghosting en kleur problemen.

+1 gryz
@Master_duck • 3 juni 2015 16:10

Het heeft te maken met "overdrive".
Hardware fabrikanten die proberen het uiteste uit hun hardware te halen. Timings net iets veranderen. Enz.

Als jij precies weet hoe dat allemaal impact heeft op elkaar, gefeliciteerd. Maar blijkbaar is het niet allemaal zo triviaal als jij denkt.

Madrox
@kiang • 3 juni 2015 16:09

Dat is een rechtstreeks gevolg van het toepassen van een variabele refresh rate: de monitor weet niet meer hoe lang het huidige frame wordt...

Volgens mee weet de monitor dat alitjjd al niet. Zover ik weet, word het beeld met vaste intervals (=Hz) ververst. Verder doet de monitor niets. De gebruiker kan wel de verversingssnelheid instellen, maar meestal is de optimale, aanbevolen frequentie de beste.

Daarom kan ik je verhaal niet helemaal volgen.

Vervolgens de kleuren:
http://nl.hardware.info/r...en-benq-getest-ervaringen
Geen woord over mindere freesync kleuren, wat voor mij aangeeft dat al dat magische kleurengedoe bij Nvidia vooral een broodje aap verhaal lijkt. Als het zo superieur is, waarom hebben de reviewers en gebruikers er het dan niet over. Maw; het klinkt allemaal fantastisch, kost je extra geld en beperkt je keuze en het resultaat is? Juist, twijfelachtig op zijn zachtst gezegd.

[Reactie gewijzigd door Madrox op 3 juni 2015 16:16]

Spekkie88
@Madrox • 3 juni 2015 18:55

Volgens mee weet de monitor dat alitjjd al niet. Zover ik weet, word het beeld met vaste intervals (=Hz) ververst.

Dat is dus JUIST verleden tijd met de komst van G-sync en adaptive sync.
Waar een monitor "vroeger" inderdaad een vastgesteld aantal Hz had en daar niet vanaf kon wijken is dat anders geworden met komst van g-sync en adaptive sync. Dit zorgt er juist voor dat een monitor geen vastgesteld aantal Hz meer ververst, maar binnen een min-max Hz range. Dit brengt echter andere "problemen" met zich mee omdat monitor fabrikanten niet meer zomaar verschillende trucs toe kunnen passen die voorheen afhankelijk waren van het vaste aantal Hz van de monitor.

1 van de trucs die monitor fabrikanten voorheen dus konden gebruiken vanwege het vaste aantal Hz is dus het hele pixel overdrive/underdrive verhaal van kiang.

Dit heeft wel degelijk invloed op de kleurweergave van een monitor, echter is het dus maar de vraag in hoeverre consumenten dit daadwerkelijk opvalt.
Maar dat geldt bijvoorbeeld net zo goed over de kleurweergave tussen TN en IPS panelen.

Er wordt alleen aangegeven dan nVidia daar blijkbaar al rekening mee heeft gehouden in G-sync terwijl het bij adaptive sync het aan de monitor fabrikanten is hier in meer of mindere mate rekening mee te houden. (if at all possible)

[Reactie gewijzigd door Spekkie88 op 3 juni 2015 19:40]

Spekkie88
@kiang • 3 juni 2015 15:46

Duidelijk verhaal, maar wat ik me vooral afvraag is het volgende over het onderstaande stukje:

Wat de Gsync module onder meer doet, is een predictief model implementeren om de frame timing van het huidige frame in te schatten, en adh daarvan heeft nVidia ook weer een eigen over/underdrive algoritme gemaakt. Dat soort modules, gezien ze over/underdrive gaan modelleren, ga je dus ook nooit los voor eender welke monitor kunnen kopen (oversteer/underdrive parameters zijn specifiek per paneel).

Vindt er ook nog extra communicatie plaats tussen GSYNC module en gpu voor het inschatten van de frame timing...
Als dit niet het geval is staat monitor fabrikanten niets in de weg iets vergelijkbaars te doen voor AS monitoren, toch?
Of daar dan wel of geen extra module voor nodig even buiten beschouwing gelaten.

+1 SG

@kiang • 4 juni 2015 10:38

Nou niet nodig ja en nee.
Wat heeft gesynchroniseerd refresh rate nodig. Een scaler die dat ondersteund.

De verantwoordelijke is degene die monitor op de markt zet. Die bepaald en verzorgt de hardware.
En in dit geval gaat het om de scaler.

De gewone consument maar ook gross of de meeste tweakers kennen scaler fabrikanten niet, ook niet de modellen en hun feature set. Maar we kenner er een die module van nV.

Scaler zijn massa productie chip. Dat nV ding is programmable custom ding. Dat maakt het duur.

Dus ja je hebt een freesync of G-sync scaler nodig.

Nee nV en AMD zijn daar niet verantwoordelijk voor.
NV wilt het liever voor hun GPU car spannen en neemt die verantwoordelijkheid over om de monitor ook nV GPU afhankelijk te maken voor deze feature.

Freesync laat men die adaptive sync scaler over aan de producenten die massa productie scalerchips maken. Met modelen mogelijk die meer kunnen dan g-sync zoals meer dan twee inputs. Maar firm ware en rekenkracht wordt bepaald door de featureset. En de firmware afdeling van monitor merken.

Het is voor het eerst dat een scaler chip houdende module tot de consument gemarketeerd wordt.

Dus wat is het werkelijke verschil.
Een custom programmable scaler is flexibler aanpasbaar en kunnen feature toegevoegd worden door firm ware.
Bij scaler chip massa productie ben je afhankelijk op release van nieuwe scaler.

Die monitor firma en scaler boeren bijten zich niet zo agressief in als nV doet.

Maar er zullen monitor komen met goedkope adaptive sync scaler chips. Maar sluit niet uit dat er ook duurdere ad.sync scaler chips komen die ook zowat alles wat gsync doet ook kan. Want je hebt paar scaler chip fabrikanten en met elk hun scaler of scaler product lijn. En AMD laat het aan die specialisten over.

Dus een freesync monitor kan afhankelijk van welke adaptive scaler en volledig ge- implementeerde firmware minder gelijk of beter zijn dan gsync scaler.

Op het moment heeft gsync voordeel van snel features uitrollen. Maar handicap van maar twee ingangen.

Dus ja als je hebt een scaler nodig nee nV had het ook aan de scaler industrie overlaten.

Dan had je hetzelfde maar met meer ingangen. Maar geen ding dat nV naar mytische proporties kan marketten.

Het heeft een reden GPU pushen door de consument te binden. Je zet je zelf schrap met gsync monitor dat je dan nV gpu moet aanschaffen. Dat is juist slecht.

Misschien dat nV later gen2 van programmable chip gebruikt met wel de optie van ruim meer dan twee ingangen.

Ik denk niet dat feature set en scaler hetzelfde zullen zijn tussen een €300,- €600,- €1200,- free-sync monitor.

Het bewijs is dat laptops zonder kunnen, omdat adaptive sync een oude tech is allang toegepast in laptops. Maar met een ander uitgangspunt energie besparing. Ik denk dat laptop firma niet staan te springen om extra chip die meer vermogen trekt naast massa productie chip met ook al die feature te pleuren.
Op zich ook geen probleem voor nV. Een laptop nv GPU kan niet zomaar vervangen worden door AMD. De hoofd reden voor die scaler module, dus die is dan niet nodig.

db87
@kiang • 4 juni 2015 11:49

FreeSync heeft ook overdrive. Alleen de eerste FreeSync monitoren die op de markt verschenen konden geen overdrive met FreeSync toepassen. Dat is verholpen met een firmware updates.

trm0001

@kiang • 3 juni 2015 15:10

""G-Sync doet namelijk aan over/underdrive correction om kleuren correct weer te geven, ook met variabele refresh rate, iets dat freesync niet doet, waardoor er ghosting kan optreden, en kleuren er wat vervormd gaan uitzien.""

Dus je denkt serieus dat AMD met een heleboel moeite probleem 1 oplost door zijn klanten vervolgens met probleem 2 op te zadelen ? En dat ze bij AMD dan ook nog denken dat dit goed zal vallen bij hun klanten ?

Het is heel simpel nVidia was van plan om gemiddeld voor een setje G-sync hardware 150+ dollar te vragen terwijl later bleek dat dit een sigaar uit eigen doos was. Je kan veel zeggen van AMD, maar dat soort fratsen doen ze niet aan.......

+1 Scalibq
@trm0001 • 3 juni 2015 15:27

Dus je denkt serieus dat AMD met een heleboel moeite probleem 1 oplost door zijn klanten vervolgens met probleem 2 op te zadelen ?

Nee, hij zegt dat AMD wel probleem 1 oplost (communicatie met variabele refreshrate), maar probleem 2 overlaat aan de makers van de monitor.

nVidia heeft probleem 2 opgelost, en biedt een kant-en-klare G-Sync module aan.
In hoeverre fabrikanten dit zelf goed oplossen voor FreeSync, dat valt nog te bezien.
Het schijnt dat de huidige FreeSync-monitors inderdaad last van ghosting etc hebben.

trm0001

@Scalibq • 3 juni 2015 15:38

[...]
Nee, hij zegt dat AMD wel probleem 1 oplost (communicatie met variabele refreshrate), maar probleem 2 overlaat aan de makers van de monitor.

nVidia heeft probleem 2 opgelost, en biedt een kant-en-klare G-Sync module aan.
In hoeverre fabrikanten dit zelf goed oplossen voor FreeSync, dat valt nog te bezien.
Het schijnt dat de huidige FreeSync-monitors inderdaad last van ghosting etc hebben.

Opmerkelijk dat je na ruim 100 nvidia posts in het AMD topic toch een AMD label hebt gekregen. Dat even terzijde, graag een linkje van de blijkbaar grootschalige problemen met Freesync mbt ghosting.

Verder bied nvidia geen kant en klare maar wel een peperdure sigaar uit eigen doos schijnoplossing. Je zal er maar in trappen.....

Fabrikanten zullen Freesync uiteraard prima implementeren al zal er heus wel een budget prut monitor te vinden zijn die G-sync of Free-sync weet te verzieken. Dat hou je altijd. Net als mensen die maar blijven beweren dat duurder altijd beter is.

@hieronder: ga AUB een ander of jezelf vertellen wat wel en niet mag maar niet mij. Alvast vriendelijk dank voor de medewerking.

[Reactie gewijzigd door trm0001 op 3 juni 2015 16:12]

+1 gryz
@trm0001 • 3 juni 2015 16:08

Jij denkt dat je een perfecte monitor krijgt, enkel en alleen door de Adaptive Sync feature van het DP1.2a protocol te gebruiken. Dat dacht AMD ook.

Inmiddels begint het voor buitenstaanders duidelijk te worden dat G-Sync iets meer doet dan alleen Adaptive Sync in het protocol te gebruiken. Als jij dat niet wilt begrijpen, prima. Maar niet zo verongelijkt doen.

db87
@Scalibq • 4 juni 2015 12:23

Ghosting had te maken met de aller eerste FreeSync monitoren die niet instaat waren om overdrive samen met FreeSync toe te passen. Ook dat is inmiddels verholpen met een firmware update.

PC Perspective had hier een filmpje van inderdaad. Waar PC Perspective echter de plank compleet mis sloeg was door te claimen dat dit aan AMD FreeSync zou liggen. PC Perspective gaf AMD's FreeSync een slechte naam terwijl het aan de monitor fabrikanten lag.

In de comments werd destijds door PC Perspective niet gereageerd op de vraag waarom ze niet contact hadden opgenomen met AMD en de monitorfabrikanten.

Sp3ci3s8472

@Luukwa • 3 juni 2015 13:56

Dat klopt niet helemaal, het is in Laptop schermen mogelijk omdat deze al vaak beschikken over de eDP standaard. Deze ondersteunt al een variant van Adaptive Sync, daarom kan Nvidia dit ook op laptops uitbrengen zonder extra chip (althans denk ik

).

@benbi
Inderdaad heb het bron artikel nog een keer goed doorgelezen. Maar moet de scaler dan niet al adaptive sync ondersteunen, die kunnen ze namelijk niet opnieuw programeren (het is geen FPGA)?
Dus indien er al monitoren zijn met een goede scaler dan zou het kunnen als de fabrikant er firmware voor wil maken?

Wat overigens ook interessant is:
http://www.tftcentral.co....htm#benq_xl2730z_firmware
Firmware update die de overdrive fixed als er gebruik wordt gemaakt van Freesync.

[Reactie gewijzigd door Sp3ci3s8472 op 3 juni 2015 17:19]

benbi
@Sp3ci3s8472 • 3 juni 2015 16:38

Maar in het artikel staat het volgende:

Een standaardmonitor zou alleen nieuwe firmware nodig hebben om dit werkend te krijgen.

Dit impliceert dus dat een bestaande monitor dit ook zou moeten kunnen met een FW update.

Ik vrees alleen dat er maar weinig fabrikanten zullen zijn die deze upgrade zullen aanbieden. Ze moeten immers meer monitoren verkopen.

+1 xavalon
@benbi • 3 juni 2015 17:47

Nieuwe firmware op een standaard monitor?! weet niet maar ik heb nog nooit op een standaard monitor een firmware update mogelijkheid gezien. Wellicht dat dit op duurderde modellen kan, maar op een standaard monitor van pak hem beet max 200 euro?

En hoe zou dit dan kunnen, via de HDMI kabel? (welke op zich wel netwerkdata zou kunnen transporteren).

+1 haarbal
@benbi • 3 juni 2015 17:59

Misschien dat de al bestaande freesync schermen met een firmware update ook over hdmi freesync kunnen. Goed, de vraag is wat heb je eraan.

Gewone non freesync schermen gaat natuurlijk nooit werken, weet ook niet waarom tweakers dit soort misleidende zinnen in hun artikelen zet.

+1 Fredi
@benbi • 4 juni 2015 01:13

Ik denk dat voor Freesync ook een specifieke controller nodig is, in het artikel van Realtek. Dus met nieuwe firmware alleen zal het niet lukken.

Luukwa
@Sp3ci3s8472 • 3 juni 2015 13:56

Dat zal het zijn inderdaad, verkeerd geïnterpreteerd dus! Sorry.

freshy98
@Luukwa • 3 juni 2015 13:52

Waar blijkt dat uit? Link oid.

Ik speel niet veel meer op mijn PC, maar speel nu weer wat Diablo 3 en merk daar gestotter. Niet continue, maar irritant genoeg.

knool
@freshy98 • 3 juni 2015 14:09

voor laptops iig
nieuws: Nvidia bevestigt na test dat G-Sync voor laptops geen hardwaremodule vereist

[Reactie gewijzigd door knool op 3 juni 2015 14:09]

db87
@knool • 4 juni 2015 12:25

Nvidia's laptop G-Sync is technisch gezien AMD's FreeSync.

+1 Fredi
@Luukwa • 4 juni 2015 01:10

Ook voor freesync zul je denk ik een nieuwe monitor moeten kopen. In het artikel wordt melding gemaakt dat daar een controller voor nodig is, hier van Realtek.

Toettoetdaan

@eL_Jay • 3 juni 2015 14:41

Klein beetje kort door de bocht denk ik.

Mantle was gewoon nog in Beta en zou daarna beschikbaar zijn. Nu is het voor grote delen overgenomen door MS in DX12.
Adaptive sync is een VESA standaard geworden en is daarmee gewoon beschikbaar voor Intel en nVidia.
VESA 4K support (Display ID v1.3) is ook door AMD gepushed.

Adaptive sync naar HDMI krijgen zou net ze relevant voor de markt kunnen zijn als de andere zaken die ze aanpakken.

0 Scalibq
@Toettoetdaan • 3 juni 2015 14:50

Mantle was gewoon nog in Beta en zou daarna beschikbaar zijn. Nu is het voor grote delen overgenomen door MS in DX12.

Nee, DX12 is door MS zelf ontwikkeld, met hulp van nVidia, Intel en verschillende game/graphics-bedrijven.
AMD heeft Mantle 'gedoneerd' aan Khronos, en deze nemen het mee in de opvolger van OpenGL: Vulkan.
Vulkan neemt Mantle wel voor een deel over.

Bliksem B
@Scalibq • 3 juni 2015 15:05

[...]

Nee, DX12 is door MS zelf ontwikkeld, met hulp van nVidia, Intel en verschillende game/graphics-bedrijven.

Heb je hier een bron van? In het artikel van Nvidia kan ik hier niks over vinden. Behalve dat ze hun drivers hebben aangepast en dat zowel MS als Nvidia zeg in blijven zetten op gaming... Als je doelt op samenwerking door middel van drivers, dan is Nvidia's aandeel net zo groot als die van Intel en AMD.

AMD heeft Mantle 'gedoneerd' aan Khronos, en deze nemen het mee in de opvolger van OpenGL: Vulkan.
Vulkan neemt Mantle wel voor een deel over.

Beide kloppen niet. Het idee van Mantel was dat er "closer to the metal" geprogrammeerd kon worden. Iets wat voor die tijd niet kan bij zowel OpenGL of DX. Door de ontwikkeling van Mantle is het hele closer to the metal programmeren in een stroomversnelling gekomen, zowel voor DX als voor OpenGL. DX heeft dat gedeelte overgenomen van Mantle, maar de code zelf is in beheer van OpenGL. Zoals in dit artikel ook wordt aangegeven.

Zoals blijkt:

When I first talked to AMD about the next-generation API at APU13, the developers candidly told me that the long-term goal was to get Microsoft and the Khronos Group in charge of OpenGL to adopt a Mantle-like architecture. The entire point of Mantle was to spur game development and drive the adoption of a better standard.

Was AMD's intentie nooit om een nieuwe standaard te ontwikkelen, alleen om betere prestaties te behalen. Wat ten voordele is voor AMD, zodat met langzamere hardware (AMD's eigen APU's en low budget videokaarten) ook fatsoenlijk te gamen is.

[Reactie gewijzigd door Bliksem B op 3 juni 2015 15:11]

+1 Scalibq
@Bliksem B • 3 juni 2015 15:11

Heb je hier een bron van? In het artikel van Nvidia kan ik hier niks over vinden.

Staat er letterlijk in:
"Our work with Microsoft on DirectX 12 began more than four years ago with discussions about reducing resource overhead. For the past year, NVIDIA has been working closely with the DirectX team to deliver a working design and implementation of DX12 at GDC."

Als je doelt op samenwerking door middel van drivers, dan is Nvidia's aandeel net zo groot als die van Intel en AMD.

Nee. AMD was te druk bezig met Mantle blijkbaar, en heeft zich bij DX12 niet echt laten zien tot begin dit jaar.

Door de ontwikkeling van Mantle is het hele closer to the metal programmeren in een stroomversnelling gekomen

Nee... Door de standaardisering op DX11+-hardware is closer-to-metal programmeren mogelijk geworden, op het PC-platform dan. Op consoles was het altijd al mogelijk, omdat er geen variatie in hardware was.

Mantle is eerder een gevolg dan een oorzaak.

DX heeft dat gedeelte overgenomen van Mantle

Afgezien van het feit dat DX12 al eerder in ontwikkeling was, hebben ook eerdere versies van DX op de Xbox een low-level API aan boord.
Het is eerder dat Mantle dingen van de Xbox One/PS4 heeft overgenomen dan andersom. XB1/PS4 waren er immers eerder dan Mantle.

Was AMD's intentie nooit om een nieuwe standaard te ontwikkelen, alleen om betere prestaties te behalen. Wat ten voordele is voor AMD, zodat met langzamere hardware (AMD's eigen APU's en low budget videokaarten) ook fatsoenlijk te gamen is.

Ook AMD moet geweten hebben dat het nooit een haalbare kaart zou zijn om Mantle breed gesupport te krijgen in games.
Dus Mantle is nooit meer geweest dan een showcase van AMD, leuk promotiemateriaal.
Verder een leuk opstapje voor Vulkan, maar het is tekenend dat Mantle er is, en dat AMD niet meteen samen met Khronos aan Vulkan werkte.

[Reactie gewijzigd door Scalibq op 3 juni 2015 16:08]

+1 jeroen7s
@Scalibq • 3 juni 2015 15:42

Verder een leuk opstapje voor Vulkan, maar het is tekenend dat Mantle er is, en dat AMD niet meteen samen met Khronos aan Vulkan werkte.

de eerste keer dat er ooit over Vulkan (of GLnext zoals het daarvoor gekend was) gesproken was, was mantle in BF4 enzo al lang gereleased, dus het is moeilijk aan een project mee te werken wat nog niet bestond

0 Scalibq
@jeroen7s • 3 juni 2015 16:07

de eerste keer dat er ooit over Vulkan (of GLnext zoals het daarvoor gekend was) gesproken was, was mantle in BF4 enzo al lang gereleased, dus het is moeilijk aan een project mee te werken wat nog niet bestond.

Uhh, dat zeg ik toch ook niet?
Toen AMD begon aan Mantle, hadden ze de keuze:
1) Zelf doen.
2) Samen met Khronos doen (Khronos beheert een aantal open standaarden, waaronder OpenGL).

Blijkbaar hebben ze er bewust voor gekozen om het eerst op eigen houtje te doen, ipv direct samen te werken met een organisatie die open standaarden beheert.
Zoals ik zeg, dat is tekenend, als je beweert dat je voor open standaarden gaat.

[Reactie gewijzigd door Scalibq op 3 juni 2015 16:08]

+1 jeroen7s
@Scalibq • 3 juni 2015 16:21

Zoals ik zeg, dat is tekenend, als je beweert dat je voor open standaarden gaat.

ik snap jouw probleem niet? het is toch ook geen probleem dat nvidia physx op zijn eigen houtje zijn gaan bouwen? of hairworks, of cuda, of G-sync in plaats van met een open standaard organisatie te werken om het te implementeren? waarom is het dan zo'n groot probleem dat AMD mantle zelf wou bouwen, en pas later wou doorgeven?
het is niet omdat AMD een deel van hun technologie open maakt dat het opeens een 'tekenend' probleem word als ze dat eens een keer wat later pas doorgeven

[Reactie gewijzigd door jeroen7s op 3 juni 2015 16:24]

+1 Scalibq
@jeroen7s • 3 juni 2015 16:27

het is toch ook geen probleem dat nvidia physx op zijn eigen houtje zijn gaan bouwen? of hairworks, of cuda, of G-sync in plaats van met een open standaard organisatie te werken om het te implementeren?

Dat is geen probleem.

waarom is het dan zo'n groot probleem dat AMD mantle zelf wou bouwen, en pas later wou doorgeven?

Het probleem is dat AMD *doet* alsof ze zo open zijn, terwijl ze eigenlijk precies hetzelfde doen als nVidia: gewoon eerst alles zelf als proprietary oplossing ontwikkelen, en eventueel een open spinoff ervan maken als de proprietary oplossing zijn taak volbracht heeft.

Daarom zijn er nu dus allerlei AMD fanboys die claimen dat Mantle open is, zelfs *open source* is, terwijl niets minder waar is:
http://developer.amd.com/mantle/

Het enige dat ze hebben vrijgegeven is dit:
http://www.amd.com/Docume...ide-and-API-Reference.pdf

Wat vrij nutteloos is zonder de daadwerkelijke SDK die erbij hoort.
Je kunt dus wel lezen hoe je software met Mantle zou kunnen ontwikkelen. Je kunt het alleen niet daadwerkelijk ontwikkelen, omdat alles dat ze in dat document beschrijven niet vrijgegeven is of wordt.

En dan krijg je dus figuren als jij die me daar keer op keer weer op aanvallen. En dat is het probleem. Het zou fijn zijn als je je eens wat beter informeert voordat je iemand meteen verbaal te lijf gaat.

+2 jeroen7s
@Scalibq • 3 juni 2015 17:12

Dat is geen probleem.

tuurlijk, ze hadden dat ook kunnen doen, maar bij nvidia is dat natuurlijk geen probleem dat ze het niet doen, bij amd natuurlijk wel

Het probleem is dat AMD *doet* alsof ze zo open zijn, terwijl ze eigenlijk precies hetzelfde doen als nVidia: gewoon eerst alles zelf als proprietary oplossing ontwikkelen, en eventueel een open spinoff ervan maken als de proprietary oplossing zijn taak volbracht heeft.

amd doet juist precies niet wat nvidia doet,
G-sync : proprietary
freesync-> Vesa standaard
AMD tressFX : draait goed op zowel nvidia als AMD, source code te vinden in dx demo
nvidia hairworks: draait redelijk op nvidia, vreselijk op AMD, binary blob zoals altijd, hardcoded 64x tesselation, want ja, waarom zou iemand minder willen dan het maximum, stel je nu eens voor dat iemand een technologie ook op lower-end kaarten wil gebruiken, dan verkopen we toch niks

Daarom zijn er nu dus allerlei AMD fanboys die claimen dat Mantle open is, zelfs *open source* is, terwijl niets minder waar is:
http://developer.amd.com/mantle/

dus het is AMD zijn schuld dat fanboys iets roepen, en het is een zeer tekenend probleem dat personen die niet gerelateerd zijn aan AMD iets zeggen

daarbuiten werkt AMD ook aan veel meer open-source projecten, zoals beschreven in http://developer.amd.com/tools-and-sdks/open-source/
iets vergelijkbaar is bij nvidia niet te vinden

En dan krijg je dus figuren als jij die me daar keer op keer weer op aanvallen. En dat is het probleem. Het zou fijn zijn als je je eens wat beter informeert voordat je iemand meteen verbaal te lijf gaat.

misschien zou je wat minder commentaar van personen krijgen als je wat minder de fanboy uit zou hangen, en misschien kan het zijn dat jij degene bent die mensen aanvalt en dat er daarom ook mensen reageren? ik weet het niet hoor

edit: grammaticafout

[Reactie gewijzigd door jeroen7s op 3 juni 2015 20:33]

db87
@jeroen7s • 4 juni 2015 12:31

Physx was van Ageia. Ik weet niet of je de Ageia PhysX Processor Card nog kunt herinneren?

Nvidia heeft Ageia opgekocht vanwege Physx. Sindsdien is Physx ten dele ook een belangrijk marketing instrument geworden.

0 Vegettokai
@Scalibq • 3 juni 2015 15:42

Swalib. NIEMAND neemt jouw serieus. Je loopt altijd te bashen op AMD gerelateerde onderwerpen.

Ben jij ook niet een tijdje op hwi actief geweest?

Ludo??

0 Scalibq
@Vegettokai • 3 juni 2015 16:05

Swalib. NIEMAND neemt jouw serieus. Je loopt altijd te bashen op AMD gerelateerde onderwerpen.

Gek genoeg heb ik blijkbaar de hoogste karma-score in AMD-topics.

Spliffire
@Vegettokai • 3 juni 2015 16:52

Mwa die karma score, ligt dat niet alleen aan de hoeveelheid posts?

[Reactie gewijzigd door Spliffire op 3 juni 2015 17:17]

+1 Pb Pomper
@Scalibq • 4 juni 2015 01:13

[...]

Nee, DX12 is door MS zelf ontwikkeld, met hulp van nVidia, Intel en verschillende game/graphics-bedrijven.
AMD heeft Mantle 'gedoneerd' aan Khronos, en deze nemen het mee in de opvolger van OpenGL: Vulkan.
Vulkan neemt Mantle wel voor een deel over.

Ongeacht wie er verantwoordelijk is voor Dx12, het is zeer onwaarschijnlijk dat Dx12 deze functionaliteit zou bieden als AMD niet met Mantle was gekomen. DirectX heeft de laatste versie nou niet echt veel bijzonders toegevoegd.

+1 Scalibq
@Pb Pomper • 4 juni 2015 09:24

Hoezo is dat onwaarschijnlijk?
Waar baseer je dat op?
Ik ben zelf graphics-ontwikkelaar, en ik zit zelf in het DX12 early access program.
Ik weet wat er speelt.
En ik weet dat oa nVidia al sinds de eerste Fermi met nogal wat ideetjes speelt die in DX12 en Mantle zijn terechtgekomen. Een deel daarvan kun je ook in NV-extensies voor OpenGL terugvinden.
Is het ook 'toevallig' dat DX12 op alle Fermis en hoger draait, terwijl dat bij AMD niet het geval is?
En dat AMD's GCN veel meer lijkt op Fermi dan hun eerdere DX11-kaarten, die NIET DX12-capable zijn?

DirectX heeft de laatste versie nou niet echt veel bijzonders toegevoegd.

De laatste versie was DX11, en die had behoorlijk wat 'bijzondere' dingen, zoals DirectCompute en tessellation.
Ja, het is alweer uit 2009, dus de hardware is wel iets veranderd intussen.
Mantle is een slap aftreksel van de APIs die MS en Sony voor de XB1/PS4 hebben ontwikkeld.

[Reactie gewijzigd door Scalibq op 4 juni 2015 09:26]

misterbennie
@eL_Jay • 3 juni 2015 14:22

Adaptive Sync (Freesync) zit al in de DP 1.2a standaard, dus daar hoef je geen 3de standaard voor uit te vinden.

Nvidia heeft zijn eigen (proprietary, dus geen standaard) ) implementatie om tearing en stuttering te voorkomen namelijk Gsync.

De referentie naar Mantle is mij in de context van dit verhaal een beetje onduidelijk.

+1 ghost010
@eL_Jay • 3 juni 2015 14:40

AMD heeft bij de aankondiging gezegd dat als nvidia er gebruik van wilt maken, dat dat mag.
En niet alleen voor nvidia.

Maar Nvidia zelf heeft nooit interesse getoond.
Naast dat stond mantle ook nog in zijn kinder schoenen en moest toen nog bewezen worden.

Darsstar
@eL_Jay • 3 juni 2015 14:49

Een derde standaard? Nee bedankt!
https://xkcd.com/927/

Als NVidia nou zorgt dat G-Sync modules ook displayport 1.2a ondersteunen, en dus freesync, dan zou G-Sync een soort(!) superset zijn geworden van Freesync.

boe2
@eL_Jay • 3 juni 2015 15:01

Euh....

AMD heeft zelf beslist om hun mantle technologie over te dragen naar een meer open oplossing, net omdat niemand wat had aan nog een extra grafische API.

+1 TheWitcher
@Luukwa • 3 juni 2015 13:44

Het is eventueel beschikbaar voor Nvidia als ze dat willen denk ik. De keus is aan Nvidia of ze er wat mee doen.

OT: Betekend dit dat oudere monitoren dan retroactief ondersteuning voor Freesync krijgen via een firmware update? Of is het alleen voor toekomstige monitoren?

+1 BCC
@TheWitcher • 3 juni 2015 13:47

Dat kan, maar waarschijnlijk niet, want ze hebben liever dat je een nieuwe monitor koopt natuurlijk.

Sp3ci3s8472

@TheWitcher • 3 juni 2015 13:53

Waarschijnlijk is nog steeds een scaler nodig die Adaptive Sync ondersteunt. Maar dit betekent dat als je een AMD kaart hebt die Freesync ondersteunt dat je dit bij schermen met deze tech ook Freesync kan gebruiken via HDMI.

AMD moet eerst vrijgeven hoe ze dit extra protocol via HDMI 1.4a gebruiken voordat Nvidia een soortgelijke oplossing kan maken. Als het inderdaad in de HDMI standaard wordt opgenomen dan kan Nvidia dit ook gebruiken, tot die tijd zal dit waarschijnlijk alleen met AMD kaarten kunnen (tenzij Nvidia zelf met fabrikanten een soortgelijke tech maken).
Eigenlijk hoop ik dat dit een tijdje een AMD premium blijft; ze kunnen dat wel gebruiken

Umbrah
@Luukwa • 3 juni 2015 15:33

AMD heeft haar techniek open gezet en aangeboden om onderdeel van de specificaties te worden (dus nu ook HDMI). Het is aan de fabrikanten (en nVidia) om dat dan ook toe te gaan passen als 'open' patent. Het is hun keuze/bedrijfsmodel echter om dat niet te doen en dure hardware te blijven verkopen.

+1 Tourmaline
@Umbrah • 3 juni 2015 16:16

"Het is hun keuze/bedrijfsmodel echter om dat niet te doen en dure hardware te blijven verkopen."

Daar trapt op een gegeven moment niemand meer in natuurlijk. Het werkt alleen kostprijs verhogend en er zijn al gratis alternatieven.

[Reactie gewijzigd door Tourmaline op 3 juni 2015 17:22]

qlum
@Luukwa • 3 juni 2015 13:43

Het is een VESA standaard, Nvidia is ook lid van VESA dus het is aan Nvidia zelf om het te implementeren. Persoonlijk denk ik dat ze wel moeten maar tot die tijd zullen ze graag aan hun vendor lock vast klampen.

edit: spelling

[Reactie gewijzigd door qlum op 3 juni 2015 14:41]

4play
@qlum • 3 juni 2015 13:53

offtopic:
ik zie dat ik niet de enige ben die "nvidia" altijd als "nvidea" schijft

...

Spliffire
@qlum • 3 juni 2015 14:05

Zo lang de prijzen ongeveer het zelfde zijn van de monitors heeft Nvidia niet veel baat bij freesync. Het is Nvidia.en geen Nivea.

+1 Jism
@Luukwa • 3 juni 2015 15:28

Lol. Nvidia heeft de tegenhanger al in haar portfolio, maar alleen tegen betaling. M.a.w monitoren die freesync van nvidia ondersteunen zit een aparte chip in met een extra hoofdprijs. AMD bewijst dat dit alternatief ook gewoon gratis kan.

db87
@Luukwa • 4 juni 2015 11:36

Nvidia gebruikt deze techniek al voor haar laptops met G-sync.

Deze laptops beschikken niet over een G-sync module.

[Reactie gewijzigd door db87 op 4 juni 2015 11:37]

+1 evilpin0
3 juni 2015 13:47

Tearing en stutter wordt verminderd niet voorkomen. : http://support.amd.com/en-us/search/faq/212

Kan dit ook beamen, heb zelf alsnog zeer lichte tearing met freesync. Maar om eerlijk te zijn is dat verwaarloosbaar. Goede techniek

+1 Scalibq
@evilpin0 • 3 juni 2015 16:51

Dat is vreemd... Stutter kun je niet altijd voorkomen, dat zit vooral in de software-kant (drivers, OS, game engine, achtergrondtaken), maar het hele doel van G-Sync/FreeSync is om de tear-free beelden van vsync te hebben, zonder de beperking dat je GPU een bepaalde vaste framerate moet halen.
Tearing moet gewoon 100% weg zijn, anders is het geen 'sync'.

db87
@evilpin0 • 4 juni 2015 12:41

Dat laatse ligt vooral aan de (door DirectX 11 gebottlenecked / slecht geoptimaliseerd) games. Van Witcher 3, Watch Dogs, Far Cry 4, AC Unity en wat ik wat nog meer weet je dat die games ansich al frametime problemen hebben. Die games gaan nooit 100% vloeiend draaien met frametimes die in overeenstemming zijn met de framerate.

Flashbot
3 juni 2015 14:35

Wat ik me eigenlijk afvraag of dit ook werkt bij TV's die aan een decoder zitten?

Daar valt volgens mij ook wel wat te verbeteren qua 'vloeiheid'

+1 gryz
@Flashbot • 3 juni 2015 15:09

Bij TVs is er altijd een constant ritme van binnenkomende frames. Iedere 20 milliseconden een nieuw beeldje. Of iedere 16.66ms. Of 23.97 keer per seconde. Er is geen stotter van frames zelf. Als het niet vloeiend is, dan komt dat door het "source material". Datgene wat je ziet in de film is niet vloeiend.
Bij games is dat anders. Daar worden de frames in een semi-willekeurig ritme aangeleverd. Als je die probeert in een vast ritme weer te geven, dan krijg je stotter (omdat sommige beeldjes 2x zullen moeten worden weergegeven. En sommige misschien geskipt worden). FreeSync en G-Sync laten het beeldscherm dan sommige beeldjes kort en andere lang zien. Dat vermindert dan de stotter. Maar als je ieder beeldje regelmatig binnenkrijgt, dan valt er niks te verbeteren.

h4ze
3 juni 2015 15:16

ik vind het volgende, als ik een gpu en een monitor koop van wat voor merk dan ook dan moet dat gewoon werken out of the box, zonder stotteren/tearing. dit achterafgedoe is een resultaat van eerdere rotzooi die ze uitbrachten en die dus niet werkt, en nu moet jij als consument maar speciale monitors/kastjes firmware/ nieuwe videokaart gaan regelen...
omgekeerde wereld zo.
en sowieso zijn hdmi standaarden een grap, er zijn zoveel combinaties van tv,receiver,blue ray spelers en noem het maar op die niet met elkaar werken of storen...

[Reactie gewijzigd door h4ze op 3 juni 2015 15:22]

+1 Tourmaline
@h4ze • 3 juni 2015 16:19

Dat komt dus juist omdat sommige fabrikanten zich niet aan de standaard houden. Deden ze dat wel, waren er ook niet zoveel problemen!

[Reactie gewijzigd door Tourmaline op 3 juni 2015 17:23]

player-x
3 juni 2015 13:49

Ik vraag me af, als het voor HDMI werkt, werkt het dan ook voor DVI, gezien de vele overeenkomsten tussen de twee standaarden qua aansturing van video.

+1 nl-chrs
3 juni 2015 14:13

"standaard-Realtek-tcon" hoe weet ik of mijn scherm ( http://www1.euro.dell.com...-u2913wm&cs=nlbsdt1&s=bsd) dit heeft?

+1 ro8in
3 juni 2015 14:36

Nou nog wachten op de G-sync/FreeSync converters

holhuizen
3 juni 2015 14:41

Mooi, al ben ik wel benieuwd of dit net zo goed gaat werken als de displayport versie, maar als het vergelijkbaar werkt, geldig ! Zo word Freesync uiteindelijk net zo breed verspreid dat het over een aantal jaar standaard op elke monitor terug te vinden is.
Wat Nvidia hiertegen gaat doen, ja geen idee, maar Nvidia is nogal fan van harde concurrentie strijd... ze houden er niet zo van om AMD gelijk te geven, door hun standaard aan te nemen ipv G-sync. Als ze consument niet kunnen overtuigen dat hun standaard " beter" is is de kans groot dat ze FreeSync zullen gaan gebruiken, maar dat dan hun eigen naam zullen geven.

Echter vraag ik me af of Freesync ooit een HDMI standaard word, aangezien Intel nogal wat te zeggen heeft in de HDMI vereniging, en die hebben het niet zo op AMD standaarden.

cdwave
3 juni 2015 15:54

Ik dacht eigenlijk meteen aan embedded systemen, en niet zozeer aan gaming.

Zo'n HDMI connectie stuurt 60 keer per seconde zo'n 1920x1080x3 bytes aan informatie over de lijn. Dat kost best veel energie. Als er niks verandert op het scherm, hoef je niet zo nodig een update te sturen.
Simpelweg naar een lagere refresh terug vallen betekent een significante energie besparing. Niet voor je gamingmonster, maar voor een ARM bordje met een TDP van 1W is dat een behoorlijk verschil.

0 computerjunky
3 juni 2015 16:18

Zolang iets geen standaard is interesseert het me helemaal niets.

Als ik dit nu aanschaf en later een nvidia kaart koop ben ik het haasje en andersom ook.

In tegenstelling tot wat mensen denken groeit het geld niet op mn rug.

1 2 Volgende

Op dit item kan niet meer gereageerd worden.

Cookies op Tweakers

AMD demonstreert FreeSync-over-hdmi

Lees meer over

Gerelateerde content

Sorteer op:

Weergave:

Reacties (146)