De prestaties van Windows 10

Snelheid, accuduur en DX12

Prestaties en accuduur

In onze review van Windows 10 gingen we primair in op de gebruikservaring en alle vernieuwingen op visueel en appniveau, omdat daar de grootste wijzigingen te vinden zijn ten opzichte van Windows 8. Dat betekent echter niet dat er onder de motorkap niets gewijzigd is. Het interne versienummer is zelfs opgehoogd van 6.2 bij Windows 8 naar 10.0 voor Windows 10, al is die sprong natuurlijk ook gemaakt omdat versie 10.0 mooi aansluit bij de productnaam.

Om te kijken welke invloed Windows 10 op een bestaande laptop of desktop heeft, hebben we drie systemen met Windows 8.1 van een upgrade voorzien. Voordat we dat deden hebben we verschillende benchmarks en tests gedraaid. Na de update hebben we deze nogmaals gedraaid. Zo hoopten we te achterhalen of er verschillen zijn in prestaties en, bij een laptop, in accuduur. Daarnaast keken we kort naar DirectX 12, de nieuwste versie van Microsofts graphics-api, die betere prestaties moet opleveren bij systemen die cpu-limited zijn.

Op laptopvlak hebben we een Asus UX31A gebruikt, ook bekend als de Zenbook Prime. Deze is uitgerust met een Core i7-3517U en 4GB werkgeheugen. Daarnaast hebben we de tests op een Surface Pro 3 gedraaid met een Intel Core i7-4650U en 8GB ram. Ons gebruikte desktopsysteem beschikte over een Intel Core i7-3960X en 8GB ram.

Prestaties

We zijn onze tests begonnen met PCMark 8 Home, waarbij we gpu-versnelling hebben inschakeld, een test die verschillende handelingen uitvoert die passen bij 'normaal thuisgebruik', zoals webbrowsen, tekstverwerken, foto- en videobewerkingen, en het spelen van eenvoudige games.

Onze twee laptops laten in deze test een bescheiden winst zien bij de overstap naar Windows 10. Waar dat aan ligt is moeilijk te zeggen; misschien bevatten Intels drivers voor Windows 10 nieuwe optimalisaties of houden de cpu's hun turbosnelheid langer vast. Op het desktopsysteem valt de score op Windows 10 net iets lager uit.

Om de gpu-prestaties te testen hebben we 3DMark gebruikt, waarbij we de Cloud Gate-test draaiden op de laptops, terwijl ons desktopsysteem het zwaardere Firestrike te verduren kreeg.

....

Ons snelle desktopsysteem presteert onder Windows 8.1 en 10 identiek. De laptops laten echter opnieuw een leuke prestatiewinst zien. De subscores laten zien dat dit vooral komt door een hogere score op graphics-vlak.

Accuduur

We hebben de laptops aan twee acccutests onderworpen: onze zelfontwikkelde webbrowsetest en de ingebouwde accutest van PCMark 8.

De Surface Pro 3 zet bijna identieke scores neer onder Windows 8.1 en 10, maar de UX31A laat in beide tests een kleine verbetering zien.

Microsoft Edge

In onze Windows 10-review gingen we al in op Microsoft Edge, de browser die Internet Explorer vervangt. Edge vinden we in het dagelijks gebruik een vlotte browser, die snel reageert en soepel scrollt, ook met verscheidene tabs open. Dat zegt echter nog niets over de onderhuidse renderengine, die de webpagina's rendert, en de snelheid waarmee dat gebeurt. Om daar iets meer over te kunnen zeggen hebben we Edge op het eerdergenoemde desktopsysteem afgezet tegen de nieuwste versies van Internet Explorer, Chrome en Firefox.

....

Uit deze verzameling tests blijkt dat Edge in ieder geval sneller is dan Internet Explorer, zowel als het gaat om javascript-prestatie als wat WebGL-snelheid betreft. De verhouding tot Chrome en Firefox wisselt. In de WebGL-test is Edge duidelijk langzamer en ook bij Peacekeeper moet het genoegen nemen met een derde plek. In de Octane-test, die nota bene van Google is, komt Edge echter als snelste uit de bus en in de Kraken JavaScript-benchmark doet het nauwelijks onder voor de rest.

DirectX 12

Het gros van de Windows-games maakt gebruik van Microsofts DirectX-api voor het renderen van graphics. De game 'praat' tegen DirectX en DirectX 'praat' vervolgens tegen de driver van AMD, Nvidia of Intel, afhankelijk van wat voor gpu je hebt. Dat is anders dan bij gameconsoles, waar ontwikkelaars de hardware direct kunnen aanspreken. Een dergelijke aanpak is bij pc's natuurlijk ondenkbaar, omdat dan rekening gehouden moet worden met een ontelbaar aantal combinaties van cpu's, gpu's en geheugenconfiguraties. Een api als DirectX, die ontwikkelaars bepaalde zaken uit handen neemt, is dus broodnodig.

DirectX moet daarvoor wel allerlei zaken bijhouden met betrekking tot de commando's die de game naar de grafische kaart stuurt: state changes van objecten, volgorde van instructie-executie en geheugenallocatie, om een paar voorbeelden te noemen. Daarbij worden opdrachten vaak niet direct verstuurd, maar eerst verzameld en in batches afgevuurd. Dat kost allemaal cpu-tijd en veel cpu-tijd is er niet. Als je een game op 60fps wil draaien, is per frame 16,6ms beschikbaar waarin alles moet gebeuren.

Heb je een moderne game-pc met een rappe cpu, dan is dat geen groot probleem. De cpu is dan snel genoeg om geen knelpunt te vormen. Bij systemen met tragere cpu's kun je echter tegen het probleem aanlopen dat de gpu bij het renderen van een frame eerder klaar is dan de cpu, waardoor de cpu wel een knelpunt vormt.

De oplossing

DirectX 12 moet dat voor een deel oplossen, vergelijkbaar met hoe AMD's Mantle dat eerder al deed. De nieuwe versie van Microsoft graphics-api's geeft programmeurs meer controle over de aansturing van de gpu. Dat betekent dat zij taken die eerst door de api afgehandeld werden nu zelf moeten doen, zoals resource tracking, maar doordat de programmeur zelf meer weet heeft van wat er allemaal gebeurt, kan dat wel efficiënter. Daarnaast wordt aan de validatiekant van de data veel tijdwinst geboekt, omdat de api die checks nu efficiënter aanpakt.

Behalve dat er dus minder cpu-cycles nodig zijn voor communicatie met de driver en videokaart, is het in DirectX 12 ook mogelijk om die opdrachten vanaf verschillende cpu-cores aan te leveren, in plaats van vanaf een enkele, zoals dat bij DirectX 11 nog het geval was.

Het effect

Alle wijzigingen hebben tot gevolg dat er minder load op de cpu komt, waardoor je ook met een tragere cpu kunt gamen zonder dat zich een knelpunt vormt. Op systemen met minder krachtige cpu's moeten games met DirectX12 in verhouding dus sneller draaien. Op papier verandert er helemaal niets voor systemen die wel over genoeg cpu-kracht beschikken; daarbij moet je geen grote prestatiewinst verwachten. Datzelfde zagen we overigens al bij Mantle.

Natuurlijk kunnen gameontwikkelaars ervoor kiezen om die vrijgekomen cpu-cycles aan andere zaken te besteden, zoals geavanceerdere physics-berekeningen.

De praktijk

Wat DirectX 12 in de praktijk voor pc-gaming gaat doen is nog niet te zeggen, want er zijn nog geen games die de api ondersteunen. Overigens hebben veel grote ontwikkelaars al wel aangegeven ermee aan de slag te gaan en de veelgebruikte Unreal Engine heeft bijvoorbeeld al DirectX 12-support.

De enige test die vooralsnog beschikbaar is, is de api-overheadtest van 3DMark. Deze kijkt hoeveel draw calls uitgevoerd kunnen worden onder DirectX 11, Mantle en DirectX12, en geeft daarmee een indruk van de efficiëntieverbeteringen in de nieuwe DirectX-versie.

Elke keer als een game iets wil veranderen aan de scene op het scherm, kost dat één of meerdere draw calls. Denk daarbij aan het renderen van geometrie, het tekenen van een texture of aanbrengen van een shader. Het is daarom zaak om zoveel mogelijk van die calls in een bepaald tijdsbestek te kunnen doen. Dat wordt bij DirectX 12 dus bereikt door de overhead sterk terug te dringen en ervoor te zorgen dat alle cpu-threads commando's kunnen aanleveren.

We hebben deze test zowel op ons desktopsysteem als op de meer bescheiden Surface Pro 3 gedraaid. Op het desktopsysteem hebben we de i7 3960X op verschillende manieren getest: met twaalf threads, met zes threads en met slechts één thread.

Het verschil tussen DirectX 11 en 12 is overduidelijk, en ook Mantle weet de oude DirectX-versie uit het water te blazen, al was dat natuurlijk al bekend. Interessanter is dat DX12 nog minder cpu-gelimiteerd lijkt dan Mantle. Schalen we namelijk terug naar één core zonder hyperthreading, dan weet de nieuwe DirectX-versie nog steeds een behoorlijke score neer te zetten, terwijl Mantle ver terugzakt. De Surface Pro 3 laat zien dat ook de minder krachtige Intel-dualcore-cpu met zwakke igp profijt heeft van DX12.

Helaas zijn er op dit moment geen andere cijfers die we over DX12 kunnen publiceren. Wil je dus weten hoeveel verschil de nieuwe api daadwerkelijk in games zal maken, dan moet je geduld hebben tot het moment waarop die games uitkomen. Vermoedelijk zullen we de eerste games met DirectX 12-support aan het einde van dit jaar zien.

Tot slot

We hadden op voorhand geen schokkende prestatieverbeteringen verwacht van Windows 10 en die zijn er dan ook niet. Alleen onze Asus UX31A laat in een aantal tests een verbetering noteren, al kunnen we moeilijk zeggen of dat komt door Windows 10 of wellicht door verbeteringen in een driver. De resultaten laten in ieder geval zien dat Windows 10 geen zwaarder besturingssysteem is dan Windows 8.1 en dat is goed nieuws voor wie wil upgraden.

Microsoft Edge is wat rendersnelheid betreft zeker een vooruitgang ten opzichte van Internet Explorer, en weet Chrome en Firefox in een aantal testscenario's te evenaren. Er zijn echter ook scenario's waarin de jonge browser achterloopt.

Over DirectX 12 kunnen we ten slotte helaas nog weinig zeggen. De api-overheadtest laat zien dat er veel meer draw calls verwerkt kunnen worden, maar meer dan dat weten we nu nog niet. Het is aan de ontwikkelaars om iets te gaan doen met die extra vrijheid en lagere cpu-overhead, zodat games in de toekomst misschien niet alleen beter draaien op low-end systemen, maar ook wat extra's kunnen bieden op high-end systemen. Zodra de eerste DX12-games uit zijn, komen we daar uitgebreid op terug.

Reacties (361)

[sKweezr]

Wel jammer dat je bij nieuwe Windows toch vaak problemen ziet met professionele muzieksoftware. Ook nu bij Windows 10 heeft Steinberg (van Cubase) geadviseerd niet te updaten omdat er performance en timings-issues zijn, zowel met audio als MIDI.

Voor mij daarom helaas nog niet naar Win10...

[Verwijderd]

Persoonlijk onder FL Studio 12 , Reaper 4.7x en Sonar Platinum geen problemen op Windows 10. Geen bugs, geen latency issues, geen timing issues, geen midi issues.....een happy muzikant onder Win10 hier.

Zelfs de tech preview deed goed werk met bovenstaande progs en toepassingen. Steinberg is, euhhh, tja...lees fora

Daarnaast heb ik ook letterlijk 0 (nul) issues met de bestaande USB apparatuur en al geïnstalleerde plugins. iLok en e-lic moesten opnieuw geïnstalleerd worden, maar de activated plugins bleven gewoon werken. Ook na de herinstallatie van deze apps een complete smooth experience!

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[Nibbz]

Ableton Live gebruikers moeten uitkijken.

Ableton Live 9 start niet op met Windows 10. Blijft hangen op initializing

Wellicht dat Ableton Live 10 dit oplost (lol.. I see what you did there Ableton )

[echtwaarisdatzo]

Geen problemen met Ableton hier, in de test versie van een paar maanden terug maar liefst.
Moet nog wachten op mijn legitieme versie.

[Nibbz]

Hmm lees toch hier en daar dat er veel problemen zijn.

Ik wacht het nog ff af, Ableton 10 komt er toch binnenkort aan .. geen zin in plugin hell

[JDFS]

Hier draait Ableton 9.2 super op mijn Windows 10 (ook testversies gedraaid). Sterker nog, beste muziek heb ik nu op m'n Windows 10 bak gemaakt!

Ableton 10 komt er IMO nog lang niet aan, Ableton 9 is pas 2,5 jaar geleden gereleased en 9.2 is nèt uitgebracht. Denk dat Ableton 10 (X?) pas in 2016 of 2017 uitkomt. Ik hoop dat ze de native devices (o.a. Analog en Operator) updaten, waarbij meerdere devices gebruik kunnen maken van een expansion view zoals EQ8. En Mixer in Arrangement View!!!

[volt9]

Hier ook geen problemen met Ableton 9.2

[Zev]

Leuk om te lezen, want ik wou wachten met upgraden van W8.1 naar W10 omdat ik ook wou weten of Reaper e.a. geen problemen zou ondervinden.

Ik gebruik veel zaken (VST) van Native Instruments, en ook zij raden aan om te wachten met upgraden tot ze systematisch zelf alles getest hebben. Deze pagina in het oog houden...

[SSDtje]

Kijk, native-instruments, dat is het echte werk.
Iedereen heeft daarentegen zijn voorkeur uiteraard
Ik begon al te denken, heeft nog niemand hier van dit bedrijf/ontwikkelaar gehoord.
Ikzelf gebruik hun software MACHINE, en deze werkt prima onder Windows 10.
Alleen sommige hardware van ze jammer genoeg nog niet.
Waaronder deze, en ik moet zeggen, ik mis hem nu al

[Reactie gewijzigd door SSDtje op 22 juli 2024 14:38]

[redbullzuiper]

Ik werk ook met VST's van native en vele andere in fl12. Alles werkt prima in windows 10. Geen enkel probleem gehad tot nu toe.

Het enigste kleien probleempje dat ik heb op fl studio is dat het geluid na 30 minuten gaat stotteren.

[sdk1985]

Ik heb ondertussen begrepen dat zelfs Vista drivers nog gaan werken op Windows 10 wat doet vermoeden dat dit eigenlijk een soort Vista v4 is met een nieuw Windows Display Driver Model (WDDM) en weer een nieuwe skin. Natuurlijk is dat gechargeerd en zijn er nog veel meer 'features' (in Windows 8 zat bijvoorbeeld al verbeterde storage functionaliteit met latency tracking en de mogelijkheid om transfers te pauzeren).

Maar het betreft hier geen revolutie zoals met de overstap van Windows 98>Windows XP en Windows XP>Vista. In dat geval werkte namelijk vrijwel alle randapparatuur niet meer zonder nieuwe driver.

[R-J_W]

Nou ja, dat betekend dat het drivermodel dat met Vista geïntroduceerd is (en waarmee Vista dus zoveel problemen gaf) nog steeds gebruikt wordt, met kleine updates.

[jimzz]

Dat de stap minder groot is komt natuurlijk ook door andere zaken, windows xp en vista leverden standaard veel minder drivers mee zoals dat bij 7/8/8.1 en 10 wel t geval is. Pas een windows 7 en 10 installatie uitgevoerd op 2 identieke laptops. Waar windows 10 alle drivers gevonden had, had windows 7 er een aantal niet gevonden. Daarnaast heeft de gemiddelde gebruiker meer schijruimte als in de xp tijd (gem 100gb naar gem 500/1000gb) en door deze upgrades kan Microsoft meer drivers meeleveren, overigens is er voor windows 7 of hoger al een hoger minimum schijfruimte vereist dan voor windows xp.

Waarschijnlijk zijn de verbeteringen op t oog niet baanbrekend, maar de tijden zijn veranderd door het internet en microsoft heeft wellicht geleerd van de fouten in t verleden dat ze er nu naar streven om een optimale gebruikerservaring te creëren.

[sdk1985]

Het klopt dat er toen minder standaard werkte. Logisch want er was een volledig nieuwe driver nodig (2x, zowel bij de introductie van XP als die van Vista). Nu niet, dat was nu juist het punt . Drivers voor je gamecontroller die voor vista zijn gemaakt kun je als het goed is probleemloos op Windows 10 gebruiken. Het wordt dan een stuk makkelijker.

De vraag lijkt me eerder wanneer we weer een echte revolutie krijgen met dus een ander driver model. Door Windows 10 is die vraag totaal niet meer te beantwoorden, in ieder geval niet door mij, doordat Microsoft van Windows 10 een service probeert te maken en impliceert dat die wel een aantal jaren mee moet gaan.

[Reactie gewijzigd door sdk1985 op 22 juli 2024 14:38]

[jimzz]

Klopt het is niet zo revolutionair, maar waarom het model aanpassen als het goed werkt? Of je controller nou profijt heeft van een ander drivermodel is dan maar de vraag (windows zelf zal misschien beter presteren) en ik ga er van uit dat Microsoft geen 2e vista debacle wil, door deze update zitten dalijk vrijwel alle windows 7 en hoger gebruikers op windows 10 en daarmee heeft Microsoft dan een hele grote groep te pakken, als mensen niet afgeschrikt worden door faulty of incompatible drivers en weten dat alles werkt na de upgrade zal het ze sneller naar windows 10 helpen. Als ze dan eenmaal windows 10 hebben, en omdat ze als ’service’ verder willen hebben ze alle tijd om dingen te veranderen, vooral omdat home users verplichte updates worden voorgeschoteld.

Dat het niet zo revolutionair is als toen ben ik het met je eens, maar er is wel iets revolutionairs gebeurd met de prijs van windows, herinner je die belachelijke prijs van windows xp professional nog toen het geïntroduceerd werd? Meer dan €600 euro werd er destijds voor gevraagd terwijl windows 10 pro voor minder dan €150 weg gaat bij introductie (windows 8.1 pro is zelfs te verkrijgen onder de €30 en in feite heb je windows 10 pro dan ook voor €30).

[Verwijderd]

FL behoort ook niet tot de profi pakketten he .

[Juantinto]

Ik snap dat je dat zegt. Maar kijk eerst even voordat je wat zegt

http://www.image-line.com/flstudio/powerusers.php

[Verwijderd]

hahaha..........dat valt best wel mee tegenwoordig.

Daarnaast, wanneer je mijn comment leest, zie je dat ik ook Reaper en Sonar draai. Net zo stabiel en prettig. Ook overige progjes zoals de standalone varianten van Tone2, Native Instruments (etc), draaien zeer soepeltjes!
FL Studio is een specifiek programma, maar doet echt al een behoorlijke tijd (lees jaren) gewoon goed mee.
Fruityloops was wel echt meer "enkel een sequencer". Die tijden zijn voorbij

FL Studio draait overigens van de drie die ik noemde ook echt het meest smooth op windows 10. Zeer vloeiende weergave van alle elementen in het programma en zelden een vertraging in de UI. Dit i.c.m. de snelle bureaublad switching (voor bijvoorbeeld Audition), zorgt ervoor (imho) dat ik Windows 10 op dit moment misschien al wel het meest prettige Windows OS vind.

[Koning Willy]

FL Studio heeft zo'n prettige workflow dat zelfs een legende als Armin van Buuren ermee bezig is om over te stappen van Logic Pro.

http://equipboard.com/pro...tudio-11-producer-edition
https://youtu.be/PkXE6kgtc7E?t=10m42s

[Reactie gewijzigd door Koning Willy op 22 juli 2024 14:38]

[BikkelZ]

Daar wordt hij voor betaald. Product placement.

[Koning Willy]

Volgens mij ken jij Armin van Buuren niet, of wel?

[Verwijderd]

Dat lijkt me erg sterk. (@bikkelz)

[Verwijderd]

Ook geen problemen met Presonus Studio 1 onder windows 10

[et36s]

Aandeel Windows 8 is beperkt waarom is Windows 7 niet meegenomen? Geloof dat 60% van alle Windows gebruikers nog bij 7 is gebleven.

[wow7]

Ook de opstart en sluit tijden mis ik in het geheel , ik heb het gevoel dat 10 langzamer is dan 8.1 met opstarten en sluiten.

[jimzz]

Ik heb pas iets gelezen dat de eerste paar keer dat je windows 10 opstart hij nog dingen gaat doen zoals updaten, virusscans, schijfdefragmentatie etc. Of dit werkelijk de opstarttijd aantast durf ik helaas niet te zeggen, heb op mijn eigen pc geen prestatievermindering ondervonden (al moet ik er wel bij vermelden dat ik een clean install heb uitgevoerd). Het os staat op een ssd. (I7 980x 6 core 4ghz/12gb1600ram/2x gtx770sli/180gb intel 530)

Ik heb 3 dagen geleden windows 10 (ook clean install) op een laptop gezet van een oud collega en heeft nog een hdd als os schijf, na de installatie was ik verbaasd dat een laptop met redelijke specs (I5 duo core 2,67ghz/6gb1066ram/7200rpm500gb) zo traag reageerde na een clean install. Na het openen van de taakmanager bleek dat zijn schijf op 100% gebruik zat en geen enkele applicatie gebruikte meer dan 1mb/s. Dit vond ik uiteraard vreemd tot ik de processen antimalware service en defrag.exe zag staan en hoewel ze niet aangeven veel resources te gebruiken deed het dat toch.
Ik had hem het advies gegeven het een nacht aan te laten staan, aangezien handmatig uitschakelen van deze processen niet mogelijk bleek en ook reschedule werkte niet, na iedere restart opende hij toch weer die processen.

De nacht is voorbijgegaan en volgens hem werkt de laptop vele malen beter en sneller dan toen het uit de winkel kwam (dit is natuurlijk ook te wijten aan bloatware die wordt mee geleverd bij verkoop).

Helaas heb ik dit nog niet op mijn eigen laptop getest dus kan er niet dieper op in gaan. Dit kan natuurlijk voor iedere laptop/pc anders zijn.

[itsalex]

Dat is zo. Bij mijn Lenovo e72 deed het systeem 7 seconden over het opstarten tot inlogscherm en nu 12 seconden met Windows 10.

[truffel50]

die ervaring heb ik ook.;-(

[TweakMDS]

Dit was ook mijn eerste indruk bij het beginnen te lezen van dit artikel. Misschien is het "in het wild" inmiddels minder, maar ik herinner me nog goed dat met name veel gamers juist de update naar windows 8 (en later 8.1) hebben overgeslagen.
Ik zit op mijn desktop ook nog op Windows 7, maar dat is meer omdat ik nooit echt de moeite heb genomen om te upgraden en sinds de aankondiging van Windows 10 maar heb uitgesteld.

[Bliksem B]

Dit was ook mijn eerste indruk bij het beginnen te lezen van dit artikel. Misschien is het "in het wild" inmiddels minder, maar ik herinner me nog goed dat met name veel gamers juist de update naar windows 8 (en later 8.1) hebben overgeslagen.

Dit was om de verkeerde redenen bij veel: gamers voelde zich niet aangesproken tot de kiddie interface (die in mijn optiek niet eens zo slecht was na 8.1). De prestaties waren echter soms tot wel 60% beter in Battlefield 4!: [hardware.info]

[Verwijderd]

Interface kan me eigenlijk weinig schelen voor een game station. Dat mijn X-55 H.O.T.A.S. opeens niet zou werken, zou een veel groter probleem zijn.

En daarnaast is een game station om te gamen, niet om te testen.

Dat een PC een telefooninterface heeft, zou ik voor lief nemen als de ondersteuning, stabiliteit en prestaties beter zouden zijn.

[Veenix]

Inderdaad, dit miste ik ook! Bovendien vind ik het vreemd dat er alleen drie i7 systemen zijn getest. Ik heb gisteren een oude celeron laptop geupgrade van Windows 7 naar WIndows 10 en het lijkt wel of hij vleugels heeft gekregen. Mijn ASUS laptop met derde generatie i5 daarentegen is er niet sneller op geworden. Zeker niet met opstarten en afsluiten. Deze ben ik momenteel volledig schoon aan het installeren (na de upgrade alle partities weggegooid en opnieuw begonnen)

[mvhorssen]

Ik vermoed dat je compiler suits wel draaien onder Windows 10. Vaak geven drivers van embedded hardware veel meer problemen. Wat dat betreft zou je Windows 10 misschien nog even beter links kunnen laten liggen.

[brick5492]

Tja, no flame, maar dit ligt toch echt aan het muziekprogramma zelf. Zelf gebruik ik FL Studio/Fruityloops en dit werkt gewoon probleemloos onder Win10.
Dat Cubase niet meer helemaal goed werkt onder Win10 ligt denk ik aan de manier hoe Cubase geprogrammeerd is. Het gebruikt misschien onderdelen/api's van Win8.1 die veranderd zijn in Win10 of drivers die nog niet bijgewerkt zijn.

[disweb]

Haha goed om te horen, werk hier ook dagelijks in FL dus wilde het even zeker weten. Geen problemen dus, ook niet met 3rd party plugins en enorme projecten?

[ProQuizmaster]

Quicktime en nuendo werken ook nog niet

[Droozle]

Kan iemand mij uitleggen waarom je nog Quicktime zou gebruiken onder Windows? Versie 7.6 komt uit 2009 (!), heeft geen hardware accelleratie en gebruikt 100% CPU voor het renderen van 1920x1080 video content, in plaats van <1% voor 4K (!) video als je Media Foundation gebruikt.

[itcouldbeanyone]

het adobe pakket vereist het

[VirtualGuineaPig]

uh, niet echt. .. Illustrator en Photoshop kunnen prima werken zonder QTe

[itcouldbeanyone]

quicktime 7.6 wel 7.7 niet
gister getest invb met adobe master collection die ik vanavond instaleer

[Static Don]

Het is daarom ook mogelijk om bij Apple Update bij Windows te kiezen tussen QuickTime 7.6 en 7.7. Vond het al raar maar dit verklaart het dus.

[Wim-Bart]

Quicktime 7.7.7 werkt inderdaad niet. 7.7.6 weer wel.

[brick5492]

Ik gebruik FL Studio eigenlijk alleen voor m'n hobby, en gebruik niet veel plugins (alleen Nexus). Ook heb ik niet echt 'enorme projecten' maar so far so good

[Verwijderd]

> maar dit ligt toch echt aan het muziekprogramma zelf.
> Het gebruikt misschien onderdelen/api's van Win8.1 die veranderd zijn in Win10 of drivers die nog niet bijgewerkt zijn.

Deze logica ontgaat me een beetje, het ligt aan het muziekprogramma omdat Windows 10 andere onderdelen en api's veranderd heeft? Had de ontwikkelaar van dit muziekprogramma in de toekomst moeten kijken om te weten welke onderdelen en api's hij wel/niet moet gebruiken?

[koelpasta]

Had de ontwikkelaar van dit muziekprogramma in de toekomst moeten kijken om te weten welke onderdelen en api's hij wel/niet moet gebruiken?

Nee, steinberg had gewoon een developer versie van win10 moeten nemen en daar hun zooi op aanpassen. Voor ontwikkelaars in windows 10 echt niet nieuw ofzo.
Cubase is echt niet bijzonder ofzo en andere DAWs werken blijkbaar wel.

[Nazlive]

Kan je niet een van die 'backward compatibility' opties gebruiken? Net zoals oude xp programma's? Weet ff niet meer hoe dat heet.

[brick5492]

Nou, aangezien MS dit soort wijzigingen allang had aangekondigd (en ook allerlei preview builds had uitgebracht) hadden ze zich hierop voor kunnen bereiden ja. Zoals ik al zei: Als FL Studio ook werkt op win10, had Cubase ook al kunnen werken (als ze bij Steinberg al hadden gekeken naar Win10)

[Thofra01]

Fijn dat Fl studio goed werkt, wilde net updaten naar win 10 en dacht, als FL studio niet goed werkt zou dat jammer zijn toen ik de comment boven je zag .

[Caelestis]

Ik ben er niet helemaal van overtuigd dat het ligt aan 3rd party software. Tot ongeveer halverwege het techpreview werkte bijvoorbeeld de standaard realtek audio drivers zoals die in win8.1 echter na geloof ik versie 10041 oid ging het helemaal mis.
Realtek heeft in de tussen tijd al een paar versies uitgebracht puur voor win10 en het geluid is enigzin weer beschikbaar maar er ontbreekt nog steeds aardig wat in de drivers.
Zo kan je dus bijvoorbeeld niet een DTS signaal uitsturen over je optische uitgang.

Het probleem ligt in het nieuwe driver enforce policy in win10 wat tijdens de preview ook behoorlijk heftig reageerde op nvidia drivers en je hele systeem in de soep liet lopen met bepaalde combinaties van hardware. En dit zijn niet de soort bedrijven die laks omgaan met drivers en updates.

Dus als Cubase een paar interne drivers gebruikt wat niet door het driver enforce policy geaccepteerd worden dan kunnen ze aanpassen wat ze willen maar win10 zal het blijven negeren.

[Tarabass]

Cubase en FL kun je dan ook niet vergelijken.

[ZakKa.dev]

Ik heb voor mijn creative X-fi Titanium ook windows 10 drivers moeten downloaden die door de community zijn gemaakt en niet officieel van creative zelf zijn .

Moet wel zeggen dat die drivers beter werken dan officiele drivers die ik gebruikte op windows 8.1 van creative.

[Verwijderd]

Daar noem je ook een bedrijf... Creative staat bij mij met stip op 1 qua slechte driver support. Reden #1 dat ik m'n X-Fi eruit heb gedonderd.

Ontopic: Hier weinig problemen. 2-3 Steam games die niet wilden werken maar het perfect deden na een check van de game files.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[Umbrah]

Eigenlijk is dit de fameuze Creative Cirkel die al sinds de eerste Soundblaster AWE32/64 aan de gang is: die kaarten worden afgeleverd, en werken met de software van dat moment.

set blaster=a220 i5 d1 t4

En tadaa, Windows 3.1 had het kenmerkende trompetje. Toen kwam Windows 95 uit, en helaas, geen manier om hem goed te laten werken. Adlib kaarten wel overigens... maar geen nood, AWE32/64 werkte perfect. Tot Windows 98... koop maar een Live128... en ga zo maar door. Van 98 naar XP waren problemen, van XP naar Vista/7 (hoewel bij Vista de videokaart fabrikanten ook finaal de fout in gingen, 95% van de Vista-gerelateerde BSOD's kwamen van nv4disp.dll...), en nu, helaas, blijkbaar weer naar Win8/Win10...

Het komt er eigenlijk op neer dat de Creative-cyclus net zo gewoon is als de Zelda cyclus; of de wet van moore, of de relativiteitstheorie... of de wet van newton...

[Wim-Bart]

Ooit een voor die tijd hoop geld uitgegeven voor een AWE32/64. En toen hij het met Wiin95 niet deed was bij mij de tolerantie verdwenen naar Creatieve. Nooit meer iets van ze gekocht. En koop ook niets meer van ze, en raad mensen ook af om Creatieve producten te kopen.

Logitech maakte bijna de zelfde fout met hun driver van XP naar Vista.

[ZakKa.dev]

Ja helemaal mee eens. Echt enorm veel problemen gehad met de drivers op windows 8.
Wat probleempjes:

- switchen tussen audiomodes 'entertainment/game mode' zorgde er soms voor dat mijn hele geluid het niet meer deed en ik een restart moest doen
- De Control Panel (naam even kwijt) met het mooiere interface werkte al helemaal niet meer. Ik moest het lelijkere 'creative audio control panel' gebruiken.

Ik koop daarom ook niet meer iets van Creative... Volgende keer haal ik iets van Asus of hou ik mijn audio gewoon on board.

In Windows 10 so far so good :-)

[ElectricHead]

creative.... Praat me er niet van inderdaad. Ik heb een Audigy 2 ZS die ik met veel plezier gebruikte, o.a. om gitaar op te nemen. Met de overstap naar Windows 7 was een kaart die net 1 vorige windows versie eerder was verschenen ineens "afgeschreven"... Puur omdat de heren vonden dat er geen nieuwe drivers voor mochten komen. Lang leve iemand uit de community die vervolgens door Creative wordt gesommeerd om te stoppen terwijl hij juist mensen hielp. Vanaf dat moment heeft Creative keihard afgedaan voor mij.

[Verwijderd]

Een Audigy 2 ZS werkt onder win 7,8 en 10 perfect met de Kx drivers.

[ElectricHead]

Ik heb 'm uiteindelijk ook wel goed aan de praat gekregen. Heb 'm nog liggen voor mijn audio Workstation.

[zipje_en_zopje]

Ik denk dat het om volgende drivers gaat?
http://forums.creative.com/showthread.php?t=714135

Blijkbaar zullen we nog tot oktober moeten wachten eer er officiële drivers uitkomen. Gezien het om Creative gaat ben ik al verbaasd dat er sowieso driver updates komen.

[ZakKa.dev]

Nee die zijn al weer verouderd.

Deze gebruik ik:

Windows 10 creative x-fi drivers:
http://forums.creative.com/showthread.php?t=720562

[Sjah]

Geprobeerd, en als je dan kijkt bij de driver in apparaatbeheer, is het gewoon een oude driver. Heb ik niks aan zo een nieuw jasje, doet dan ook niks qua het probleem oplossen dat ik heb met een Titanium HD.

[ZakKa.dev]

Welk probleem heb je dan precies? Werkt tot nu toe voor mij perfect. Ik heb een X-fi Titanium (niet HD)

[Sjah]

Na elke reboot is geluid weg, en moet ik dmv een reinstall geluid terugtoveren. Oplossing die ik nu tijdelijk heb is de algemene Ms HD-driver pakken.

[ZakKa.dev]

Heb je de driver gepakt in mijn link? Ook eerst de drivers verwijderd die je nu hebt en/of disabled in device manager?

Misschien is Titanium HD toch even anders dan een normale Titanium wat betreft drivers, maar ik betwijfel het

[Verwijderd]

Creative komt pas in oktober met W10 drivers voor deze kaarten.

[Verwijderd]

Heb je een linkje?

[ZakKa.dev]

Ja zie mijn reactie op zipje

[Verwijderd]

Ik blijf stereo geluid krijgen, wat vroeger DTS was....erg jammer.
Misschien toch maar eens overstappen naar een Asus kaartje

[ZakKa.dev]

Hier geen ervaring mee. Heb je DTS geactiveerd in dat control panel van creative? (met dat zilveren interface).

Ja voor mij ook asus kaartje next time.

[Reactie gewijzigd door ZakKa.dev op 22 juli 2024 14:38]

[Verwijderd]

Ik heb een x-fi Fatal1ty, control panel werkt niet bij mij.

[ZakKa.dev]

X-fi fatality is hoe ver ik weet hetzelfde als een x-fi titanium HD. Maar uhm heb je geen 'creative audio control panel' ?

je zou toch dit moeten kunnen krijgen volgens mij:
http://i.ytimg.com/vi/OGZ4m3CFOFo/hqdefault.jpg

Misschien met de juiste drivers. Succes ermee!

[Verwijderd]

zal vanavond nog ff kijken, misschien ff clean install doen

[Verwijderd]

Hier geen ervaring mee. Heb je DTS geactiveerd in dat control panel van creative? (met dat zilveren interface).

Ja voor mij ook asus kaartje next time.

heb de asus xonar phoebus ook installatie probleem mee en dolbytheater werkt niet meer op asus webside productondersteuning niets over w10 te vinden.

[Dutch_CroniC]

Dat had ik ook, komt omdat je audio dan 2.0 is.
ik heb dat opgelost met een instelling, maar moet zo even kijken hoe als ik mijn geluid voor elkaar heb, met ms driver heb ik geen geluid.

[Dutch_CroniC]

Ik krijg er via Updatez gewoon een driver voor. Zijn die jij hebt beter? En waar merk je dat aan?

Waar kan ik ze vinden?

Tnx

[LOTG]

Persoonlijk vind ik dat dan erg slecht van Steinberg. Je kon al erg lang preview versies downloaden om je software te testen. Dat je dan bij de release geen werkend product hebt is dan ook erg onprofessioneel vind ik.

Ook de bedrijven die maar roepen dat ze geen driver/update hebben omdat het OS nog niet gereleased is vind ik slecht. Als je op de dag van release geen werkend product hebt dan loop je achter de feiten aan.

[ProQuizmaster]

Het is dus niet te wijten aan Steinberg. Het zijn de Quicktime runtimes die dwars liggen, dus het enige wat je Steinberg kan kwalijk nemen is dat ze afhankelijk zijn van Apple

[koelpasta]

Eeh,.,. cubase is volgens jouw dus afhankelijk van quicktime? Lijkt me erg raar als dat waar zou zijn.

[ProQuizmaster]

Quicktime: The latest Quicktime 7.7.7 cannot be installed on Windows 10. The older version 7.7.6 seems to work but does not include the latest security fixes and is thus not recommended.
This practically removes the video support for Cubase and Nuendo.

bron

Overigens ook netjes te vermelden dat het niet het enige probleem is, ze hebben ook latency isseus.

Wat mij doet afvragen of er ook problemen zijn als je het video gedeelte links laat liggen en een externe geluidskaart met dedicated audio drivers gebruikt

[jimzz]

Wat ik denk dat koelpasta bedoelt is dat steinberg er ook voor kan kiezen om ipv quicktime een andere player te gebruiken. Als je muziek produceert en er van afhankelijk bent zou ik wachten met upgraden, het werkt en windows 10 is niet veel anders in gebruik dan 7 of 8.1 apple zal wellicht met een update komen voor quicktime.

Een oudere versie werkt wel, dus die zou je eventueel nog kunnen gebruiken als je echt nu wilt upgraden. Je kunt ook dual boot optie kiezen. En ik ga er van uit dat de fixes voor online zaken bedoeld zijn en in mijn ervaring heb je geen internet nodig om muziek te produceren, daarmee bedoel ik dat je dan je internet verbinding uitschakelt zodat je weinig last zult hebben van de security fixes die je dan mist.
is natuurlijk niet de beste oplossing, maar dit lijken me de meest voor de hand liggende oplossingen voor als je niet kunt wachten op apple en toch naar windows 10 wilt.

[Verwijderd]

Steinberg is ook een redelijk conservatief bedrijf en al geruime tijd een dochter onderneming van het veel grotere Yamaha is.
Voorbeeld is dat voor hun hardware midi controller midi8 geen 64 bits drivers waren totdat een medewerker zelf de bestaande driver toch heeft geport naar 64 bit en die uiteindelijk toch aan de gebruikers beschikbaar werd gesteld omdat er veel vraag naar was.

Windows 10 heeft diverse verbetering gekregen voor zowel audio als midi maar daarvoor zullen er wel API's zijn aangepast waar schijnbaar nog niet iedere audio software fabrikant haar software volledig op heeft aangepast.

[Darkstriker]

Wat is dat voor excuus? Je mag als techbedrijf in deze tijd gewoon niet conservatief zijn op die manier op die jij het schetst. Heb je hoge kwaliteitseisen (misschien omdat je producten ook zeer duur zijn), dan moet je er gewoon een voldoende hoeveelheid werk in zetten om kwalitatief hoogwaardige EN up-to-date software te hebben. Dit hier levert direct reputatieschade op, en dat terwijl het makkelijk had kunnen worden voorkomen.

Dat een medewerken op eigen houtje een x64 driver moet maken is een teken van zware problemen in je software tak. Het is geen excuus ervoor om een update van een 2 jaar oud besturingssysteem waarvan al ruim een half jaar testversies van beschikbaar waren niet fatsoenlijk te ondersteunen.

[Reactie gewijzigd door Darkstriker op 22 juli 2024 14:38]

[SuBBaSS]

Nou ja, gelukkig maar dat bedrijven/organisaties die zich op professioneel gebied met Cubase bezighouden echt niet zonder meer vooraan zullen staan bij migraties als deze. Juist om redenen als deze (dat er nog wel eens, al dan niet, exotische hardware gebruikt wordt met een betrekkelijk kleine userbase van een fabrikant die ook nog eens "conservatief" is) zal er voor hen dan ook maar weinig reden zijn om over te stappen, want veel meerwaarde bieden een nieuwe browser/aangepaste interface ed. sowieso niet.

Overigens is het niet exclusief voor steinberg/yamaha; M-Audio vond het ook niet nodig om bijv. 64 bits drivers voor w7 te maken voor hun revolution series geluidskaarten, maar vervolgens wel naar hun nieuwste line-up verwijzen als "oplossing". Daarmee zijn ze in mij ook een klant kwijtgeraakt.

Hoewel je het wmb. wat overdreven stelt ("zware problemen in je softwaretak" bijv.) heb je in de basis mi. wel gelijk maar wellicht kennen ze hun userbase wel zo goed dat ze hier geen prioriteit aan stellen (vanwege bovengenoemde redenen tot niet-upgraden naar W10).

[Verwijderd]

Ik heb ook niet zo'n hoge pet op van Steinberg.
Toen ik jaren geleden van een Core2 Duo naar een Core i7 overstapte, werkte mijn Cubase ook niet meer, en moest ik upgraden naar een nieuwere versie.
Echt vreemd. Ik heb geen enkele andere software meegemaakt die op de i7 niet meer werkte.

[Cergorach]

Ik zou sowieso nog niet adviseren om naar W10 te gaan, eerst even de bugs afwachten, wat patches, etc. Geeft ook leveranciers de ruimte om nieuwe drivers en software patches te maken/testen op de productie versie van W10.

[Blokker_1999]

Sinds Windows 7 komt Microsoft reeds maanden voor de RTM versie met preview versies waardoor het merendeel van fouten en bugs gevonden word voor de release. De kans dat er nu nog ernstige problemen opduiken is dus zeer klein.

[Cergorach]

MS heeft wel eens vaker op het laatste moment in Windows versies zitten rotzooien, maar dat is inderdaad langer geleden dan W7. Maar aangezien ik W8 naar W8.1 nog recentelijk heb meegemaakt (de meest recente 'upgrade'), ben ik nog steeds erg huiverig, ook al heeft een collega van mij al flink zitten te testen gisteren en zijn de initiële resultaten positief. Measure twice, cut once.

[jqv]

De leveranciers hebben genoeg tijd gehad om drivers te maken. Deze zijn door microsoft betrokken in de ontwikkeling en krijgen steeds de nieuwste versies van de previews eerst.

Als ze nu nog moeten anticiperen op win10, zijn ze niet best bezig.
Er kan natuurlijk van alles misgaan, maar dit hoeft niet te gebeuren.
Sinds Vista heeft microsoft contact gezocht om problemen met drivers te voorkomen.

[Cergorach]

Aangezien ik nog super belangrijke en grote web applicaties tegen kom die een IE9 of zelfs IE8 nodig hebben, niet willen werken met .NET 4.5.x, etc. Dan weet ik zeker dat er nog genoeg (grote) leveranciers zijn die hun applicaties en diensten nog niet hebben klaargestoomd voor W10.

[Technomania]

Al maanden een zeer tevreden testgebruiker en zou het juist wél adviseren.
op één update na nooit een BSOD gehad oid en dat juist voor een beta.

Maar goed, meningen kunnen verschillen.

[Jo0Lz]

Ze hebben toch maanden gehad om op basis van de preview een update te maken voor Windows 10, lijkt me dat ze daar niet genoeg prioriteit aan hebben gegeven.

Ik vond de extra vrije ruimte na de upgrade (en opschonen van de rommel natuurlijk met cleanup tool) ook een welkome "verbetering" op m'n ssd

[Blokker_1999]

Mjah, maar niet iedereen kan of wil software beginnen aanpassen wanneer je niet zeker kunt zijn dat het onderliggende OS stabiel blijft. Zeker wanneer timing belangrijk is lijkt het mij belangrijk dat je een stabiel platform hebt om van te vertrekken.

[Zer0]

Maar om te testen of het onderliggende OS stabiel genoeg is voor jouw applicatie heb je wel een werkende versie van je applicatie nodig. Zo wordt het een beetje een kip vs. ei verhaal.

[jip_86]

Tja dat heet gewoon testen in productie. Die periode word juist gegeven aan ontwikkelaars om problemen voor te zijn. Voor hetzelfde geld had het om een probleem in Windows gegaan en hadden ze daar vooraf al naar kunnen kijken. Nu het zo breed uitgerold word zal een aanpassing doorvoeren in Windows waarschijnlijk wel een ander verhaal worden.

[Verwijderd]

Het probleem is in 99 van de 100 gevallen de applicatie zelf.
Microsoft verandert of verwijdert een API zelden of nooit.
De meeste problemen komen door fouten in de software, die bepaalde API-functies aanroepen met verkeerd geinitialiseerde parameters etc, die buiten de spec vallen. Of er wordt niet gecontroleerd op return-waarden van functies bv.
Door aanpassingen aan de internals van Windows of toevoegen van nieuwe functionaliteit, kunnen die foute parameters ineens ander gedrag gaan vertonen.
Onthou dit goed: "Working code is not bugfree code!"

Met nette software, die de spec op de letter volgt, heb je vrijwel nooit problemen. Er zijn dan ook genoeg applicaties te vinden die zonder problemen op vrijwel alle versies van Windows draaien, vanaf NT3/Win9x tot Win10.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[Jo0Lz]

De preview was anders vanaf 10130 behoorlijk stabiel. Hoe dan ook was de rtm hetzelfde als de huidige release, volgens mij kunnen ze op basis van de preview iig zien wat er niet goed gaat bij hun software.

Ik heb zelf de preview gedraaid met +/- 30 applicaties, en er was er maar 1 die onaardigheden vertoonde. En die is inmiddels aangepast, maar nog niet perfect.

[drs.titulaer]

Ja zit nu zelf met de gebakken peren. Windows 10 geïnstalleerd en nu doet mijn geluidskaart het niet meer. Windows zelf gaf tijdens upgrade aan dat er geen vuiltje aan de lucht zou zijn.

[Henk Poley]

Kijk eens of Snappy Driver Installer iets voor je heeft. Anderszins natuurlijk eerst op de site van de fabrikant de Windows 8.1/8/7 'audio' driver downloaden.

[Reactie gewijzigd door Henk Poley op 22 juli 2024 14:38]

[vSchooten]

Dit zul je bij alle oss'en tegen komen die op deze manier upgraden van versie. Een applicatie zal altijd pas na release een nieuwe versie voor die os kunnen maken omdat er bij beta en previews altijd nog wel veranderingen komen... Je weet namelijk niet hoe of wat er fout gaat met je applicatie in de nieuwe os...

[LCP]

Draai hier de RTM (10240 x64) i.c.m. Cubase Pro 8 x64 met MOTU ASIO drivers. De prestaties zijn bij mij ongeveer gelijk aan de situatie voorheen op Windows 8.1, maar de interface is ontzettend laggy en onresponsief. Misschien is de latency ook iets hoger dan in 8.1. Ik hoop op een snelle update voor Win10. Maar Steinberg kennende, zal die er wel snel komen. Even geduld hebben. Cubase is nu eenmaal niet een eenvoudig stuk software.

[BikkelZ]

Het is een bewezen feit dat de MIDI support sinds Windows 98 iedere versie steeds slechter wordt. En tijdens Windows 98 werden er al noodgrepen ontwikkeld zoals de Midex 8 voor Cubase en de Emagic MIDI interfaces voor Logic omdat de timings toen al niet al te strak waren.

Daardoor is OS X toch het beste platform voor MIDI (na de Atari ), ondanks dat het niet eens zo super denderend is.

Tegenwoordig zijn ze software aan het ontwikkelen om MIDI direct via een geluidskaart uit te sturen. Dat is nu al mogelijk voor CV/Gate (oude synths en modulars) en tape of andere sync (bijvoorbeeld drumcomputers of een TB-303) en het heeft als voordeel dat het superstrak loopt met je audio. Het is immers audio en je geluidskaart wordt gewoon als een dure modem gebruikt als het ware.

[Exquiza]

Voor Windows 10 heeft Microsoft een volledig nieuwe MIDI-Api geschreven.

[Verwijderd]

Thanks voor de tip. (Geldt ook voor cubase 8?) Was van plan te updaten... Nog maar even niet dus.

[echtwaarisdatzo]

Ableton geen enkel verschil. Mogelijk iets vlotter juist, maar minimaal verschil.

[Peter Li]

Helaas heb ik ook een slechte ervaring met Windows 10. Mijn Asus Vivio Tab tablet kan geen Windows 10 vervangen daar het screen geen Windows 10 kan weergeven. Heb daar Asus voor gebeld maar ik zal een ander tablet voor moeten kopen als ik Windows 10 voor 8.1 wil vervangen.
Asus adviseer ik een ieder voorzichtig te zijn voor een tablet vervanging in Windows 8.1 naar Windows 10. Koop dus GEEN Asus tablet Vivio Tab! Deze is net 2 jaar oud.

[R-J_W]

Het scherm kan geen Windows 10 weergeven??
Net even gekeken in de pricewatch, maar het is niet de resolutie. Hij voldoet verder ook gewoon aan de systeem vereisten.

Dus dan zou het een driver issue zijn. Het zou zo kunnen dat Asus, of Microsoft, of de leverancier van het scherm er al mee bezig is.
Ik zou het over een maand weer eens gaan proberen.
Wat de support zegt is bij een groot bedrijf als Asus niet iets waar je op kunt vertrouwen. De interne communicatie met de ontwikkelingsafdelingen is meestal niet bestaand.

Ik heb mijn oude HP mini 210 met intel Atom uit 2011, met Win7 Starter ook kunnen updaten.

[Reactie gewijzigd door R-J_W op 22 juli 2024 14:38]

[Spiritos]

http://pcaudiolabs.com/windows-10-for-pro-audio/

Hier zie je toch duidelijk dat Win10 op alle vlakken beter presteert dan 8.1 en bij mijlen beter t.o.v. Win7. En dat van één van de beste DAW Builders uit Nashville.

Het blijven natuurlijk benchmarks en drivers blijven altijd even afwachten maar dat heeft dan toch echt met de DAW-software te maken. WDM presteert iig significant beter. Het is nog steeds geen core audio (Mac) maar toch...

Mijn nieuwe DAW-PC met 8.1 is pas een paar maandjes out en ik ben sowieso geen early adoptor dus ik kijk voorlopig nog even de aap uit de boom maar eerlijk is eerlijk, Win 10 ziet er voor DAW's goed uit.

[JDVB]

Ik snap niet dat de grafieken van draw calls op deze manier getoond worden om te vergelijken met DX11. Dit klinkt alsof DX12 slechts een fractie van de afstand hoeft te overbruggen welke DX11 overbrugt.

Wat Wout erover zegt:

De nieuwe versie van Microsoft graphics-api's geeft programmeurs meer controle over de aansturing van de gpu. Dat betekent dat zij taken die eerst door de api afgehandeld werden nu zelf moeten doen, zoals resource tracking, maar doordat de programmeur zelf meer weet heeft van wat er allemaal gebeurt, kan dat wel efficiënter.

Ofwel, DX12 doet minder dan DX11 waardoor de game zelf meer zal moeten doen. Dit klinkt mij als broekzak vestzak. Het ene proces vereist minder CPU tijd, wat (op zijn minst gedeeltelijk) verloren gaat doordat een ander proces weer langer bezig is.

De grafieken lijken mij daarom best wel nutteloos omdat:

• Niet duidelijk is welk deel van de 'performance winst' gecompenseerd moet worden door extra werk voor de game.
• De mogelijk te maken efficientie slag hierbij niet in te schatten valt.

Daarom ben ik wel benieuwd naar wat game ontwikkelaars hiermee gaan doen, en hoe games uiteindelijk te vergelijken gaan zijn.

[Reactie gewijzigd door JDVB op 22 juli 2024 14:38]

[Madrox]

Nee, je maakt een denkfout. DX11 belast de cpu veel meer, veel meer dan nodig is. DX11 zorgt dus onnodig voor een zware cpu belasting. DX12 toont aan dat het met veel minder belasting kan, het werkt dus veel efficienter. Zo efficient, dat de cpu ruimte overhoud om nog meer rendement uit de gpu en de rest van het systeem te halen. Extra werk voor de game ? Echt, je ziet het totaal verkeerd.

Het "extra werk" waarover je praat is nu, met DX11 werk wat blijft liggen omdat de cpu onnodig zwaar belast word. De volle potentie van de gpu en subsysteem worden niet benut, DX11 remt dus de performance af. Wat, tot nu toe alleen maar "opgelost" word met een brute hardware "fix"; zwaar overklokken die cpu! Meer hitte, meer stroomverbruik. Nog steeds een slecht rendement van de cpu, maar ja, de FPS is dan wel beter. Brute oplossing en dus niet erg elegant. Met DX12 veranderd dat allemaal, ten voordele !

Microsoft hasn’t just improved their threading model,they’ve also significantly reduced the overhead on the workloads that remained single threadedd by necessity and completely removed the kernel-mode driver from the equation. The end result is CPU overhead reduction in DX12 by half compared to DX11. Which means Microsoft has essentially doubled CPU performance across four threads while running DX12 compared to DX11. I would expect an even better performance improvement across additional CPU cores.

Read more: http://wccftech.com/dx12-...pared-dx11/#ixzz3hNBkBQoR

http://wccftech.com/dx12-revealed-compared-dx11/
Overhead reduction, je weet wat dat betekend ?

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

Niet helemaal waar. Bij DX11 en lager had men alleen maar 1 thread tot hun beschikking om de GPU te voeren. Met mantle kan je simultaan meerdere cores tegelijk inzetten die praten met de GPU. Dat is dus de overhead draw test die dat netjes laat zien. DX12 doet ongeveer hetzelfde en het laat toch wel zien hoe superieur Mantle nu precies is in DX11.

[Verwijderd]

Dat is niet waar, DX11 ondersteunt 'deferred contexts', waarmee je op meerdere threads tegelijk GPU-commandlists kunt samenstellen, zij het met wat beperkingen tov de immediate context.
Zie: https://msdn.microsoft.co...op/ff476892(v=vs.85).aspx

[Madrox]

En zo heeft DX11 wel meer beperkingen waar jji, schijnbaar al devleoper omheen moet werken. Wat is jouw afkeer, ja zo lijkt het, tov. DX12 ? Echt, ik sta perplex; je zou het met beide armen moeten omarmen.

However, most developers agree there are real gains to be made with DirectX 12. That’s because, in many ways, the new DirectX breaks with Microsoft precedent and interacts with the computer’s hardware in new and potentially powerful ways.

Mag hopen dat jij tot deze groep gaat behoren, want zover ik je reacties overzie zit je eerder in het negatieve kamp.
http://www.pcgamesn.com/r...eally-think-of-directx-12

Oja, deze opmerking druist ook in tegenover jouw stelling "dat goede games wel optimaal van de hardware gebruik maken onder DX11" , met goede developers aan het roer.

“There's no such thing as a free lunch,” said another engineer. “DX11 didn't have a lot of overhead because its authors were dumb, it had a lot of overhead because it handled a LOT of details that are now the game programmer's responsibility in DX12

Dat is dus lijnrecht tegenover jouw gedachte.

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

Mag hopen dat jij tot deze groep gaat behoren, want zover ik je reacties overzie zit je eerder in het negatieve kamp.

Ik zit in het DX12 early access program, en heb zelf dus al tijden de DX12 SDK in handen, en heb ook hier en daar feedback gegeven erop tijdens de ontwikkeling van DX12.

Mijn punt is niet dat DX12 niet goed is, maar vooral dat mensen DX11 onterecht afschrijven als een waardeloze API, en DX12 nogal onrealistische performance-winst toeschrijven.
Ik hou het liever realistisch dan al dat marketing-gebral. DX12 is geen silver bullet.

[Verwijderd]

JDVB heeft wel degelijk een punt, zoals in het artikel staat:
"Dat betekent dat zij taken die eerst door de api afgehandeld werden nu zelf moeten doen, zoals resource tracking, maar doordat de programmeur zelf meer weet heeft van wat er allemaal gebeurt, kan dat wel efficiënter."

Dus de programmeur moet wel degelijk zelf meer gaan doen, reden van DirectX was, naast verschillende hardware door dezelfde API aan spreken, ook juist resource-ellende weg te halen bij programmeurs. Theoretisch moet het performance winst opleveren, omdat degene die het spel maakt weet wat er moet gebeuren ipv botte bijl van de API die misschien te vaak automatisch checkt of een pointer wel gealloceerd is, maar misschien wel meer ontwikkeltijd/ingewikkelder/meer bugs. Er zijn dus wel degelijk nadelen.

[vSchooten]

dus jij wilt een extra grote codebase met code die je eigenlijk niet nodig hebt altijd runnend op de achtergrond?

[computerjunky]

In een ideale wereld gaat de cpu echter wel wat anders doen.

De gpu neemt nu de taak over van de cpu en dat kost misschien 1 a 2% prestatie van de gpu. de cpu heeft echter (vooral bij een trage) zo goed als niets meer te doen.
Het zou mooi zijn als er effecten komen die de cpu wel kan afhandelen zodat we toch wat extra's krijgen en de cpu niet idle staat. daar heb je immers geen cpu tig euro voor.


Verder duurt het zeker nog wel 5 jaar voordat dx 12 volledig geïntegreerd is.
Kijk maar naar het aantal games dat nu nog met dx10 only uitkomen en hoeveel games gewoon geen dx11 ondersteuning hebben...

[Madrox]

De gpu neemt nu de taak over van de cpu en dat kost misschien 1 a 2% prestatie van de gpu. de cpu heeft echter (vooral bij een trage) zo goed als niets meer te doen.

Wederom een misvatting.

http://www.techpowerup.com/img/15-03-23/100f.jpg
Dit is wat DX11 nu doet, in veel gevallen. Zoals je ziet word het werk zeer slecht verdeeld.
Wat DX12 doet is niet ineens de gpu zwaarder belasten en meer werk laten doen, nee, wat DX12 en ook Mantle doet is het werk beter verdelen over alle cores en! daarbovenop haalt het onnodige "draw calls" weg uit het proces.
http://www.techpowerup.com/img/15-03-23/100h.jpg
Hier zie je duidelijk het effect; het werk word veel beter verdeeld en meer cores worden benut.

Het gaat dan ook vooral hierom:

But remember that DirectX 12 is about making the API more efficient so it can take better advantage of multi-core CPUs. It's not really about graphics cards. It's about exploiting more performance from CPUs so they don't bottleneck the GPU.

http://www.pcworld.com/ar...mance-leap-is-insane.html
Als straks de GPU harder werkt is dat een goede zaak. Je verliest namelijk geen performance, je wint performance. Omdat die performance er met DX11 niet uitgehaald kan worden. Wat alleen maar gecompenseerd word door hogere cpu-overkloks, maar dat is natuurlijk niet de goede weg.

But the good news is that every piece of hardware we tested sees a boost courtesy of DX12 - we're seeing a far higher utilisation of both CPU and GPU. The figures demonstrate in particular how under-utilised the geometry engines are on our GPUs - what other areas of the graphics hardware are also under-utilised that DX12 could potentially access? The prospects are tantalising.

http://www.eurogamer.net/...rectx-12-is-a-gamechanger

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

De kanttekening hierbij is dat dit allemaal van AMD komt, en Tweakers ook met een AMD-GPU heeft getest.
Bij AMD wordt er vrijwel niets gedaan met de extra DX11-threads, en wordt alles gebufferd voor de main-thread tot het moment van de draw call.
Dit geeft een vertekend beeld van DX11, want op nVidia-hardware ziet het beeld er al heel anders uit met multithreading:
http://www.anandtech.com/...i-overhead-feature-test/3

DX12 is nog steeds wel efficienter, maar in de praktijk zullen de verschillen ook niet zo dramatisch zijn. Dat hebben we ook met Mantle al gezien.

[Ventieldopje]

De support voor Mantle was dan ook wel erg mager, ik denk dat DX12 een veel grotere impact zal hebben. Niet alleen voor high-end systemen maar ook vooral voor low-end systemen.

[computerjunky]

Het voordeel licht juist alleen bij low end systemen omdat high end systemen als cpu's hadden die geen problemen hadden met de extra benodigde rekenkracht.

Kijk maar naar alle mantle benches. totaal geen voordeel voor high end systemen en in sommige gevallen zelfs slechtere low fps spikes.

[Madrox]

De verschillen zijn wel dramatisch, als je ziet hoeveel winst eruit geperst word met minder sterke cpu's. De winst is er ook bij zwaardere cpu's, maar dan niet vertaald in FPS, maar in cpu load.

Once DX12 comes into play though, NVIDIA’s throughput rockets through the roof as well. The GTX 980 sees an 8.2x increase over DX11ST, and a 7x increase over DX11MT. On an absolute basis the GTX 980 is consuming 15.5M draw calls per second (or about 250K per frame at 60fps), showing that even the best DX11 implementation can’t hold a candle to this early DirectX 12 implementation. The benefits of DirectX 12 really are that great for draw call performance.

Ook bij Nvidia valt er nog veel te halen. 8.2x increase, betekent ruim 800% meer draw calls per seconde. Noem dat maar niet dramatisch, ik zie het toch echt anders. Nvidia doet het inderdaad beter met DX11, maar dat het nog veel beter kan word hier wel aangetoond.

Bron, je eigen link

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

De verschillen zijn wel dramatisch, als je ziet hoeveel winst eruit geperst word met minder sterke cpu's. De winst is er ook bij zwaardere cpu's, maar dan niet vertaald in FPS, maar in cpu load.

Niet dus, zoals ik al zeg.
Mantle heeft een vergelijkbare theoretische winst in de API-calls, maar games draaien in de praktijk echt niet zo veel beter dan DX11. Dat is wat ik bedoelde.
Je vergroot hier gewoon een heel klein stukje van de game-code enorm uit.

Ook bij Nvidia valt er nog veel te halen. 8.2x increase, betekent ruim 800% meer draw calls per seconde. Noem dat maar niet dramatisch, ik zie het toch echt anders.

Ik niet, want die draw calls moeten ook nog wat doen (en dat doen ze hier niet).
Als iedere draw call de GPU even lekker aan het werk zet (zoals in echte games), dan is de winst op de draw call zelf maar marginaal tov het totaalplaatje.

[Pb Pomper]

Het is natuurlijk wel zo dat Mantle maar een klein deel van de videokaart eigenaren besloeg en nooit echt tot volle ontwikkeling is gekomen. Bij DirectX 12 zal dat een heel ander verhaal zijn.

Ik hoop dat we extra ruimte bij CPUs geinvesteerd gaan zien worden in betere physics en AI of betere audio effecten.

DirectX is voor mij de killer feature voor Windows 10. Ik had uiteraard liever gezien dat OpenGL de nieuwe standaard zou worden, maar dat gaat waarschijnlijk nooit gebeuren. Al hoop ik wel van harte op het succes van SteamOS.

Ik ben blij dat AMD Mantle heeft ontwikkeld. Volgens mij was die dreiging het enige wat gezorgd heeft voor relevante vooruitgang bij DirectX. Jammer dat MS dat niet uit zichzelf doet. Zo zie je maar weer wat monopolies doen met innovatie.

[Verwijderd]

Ik hoop dat we extra ruimte bij CPUs geinvesteerd gaan zien worden in betere physics en AI of betere audio effecten.

Ik zie persoonlijk het liefst dat dat soort dingen zo veel mogelijk naar de GPU verplaatst worden.
Maar vanwege de mogelijkheid van async shaders in DX12 moet dat ook efficienter worden.

Ik ben blij dat AMD Mantle heeft ontwikkeld. Volgens mij was die dreiging het enige wat gezorgd heeft voor relevante vooruitgang bij DirectX. Jammer dat MS dat niet uit zichzelf doet. Zo zie je maar weer wat monopolies doen met innovatie.

Erm, wanneer had MS dan wel concurrentie? Rond DX7 is OpenGL al afgehaakt, en toch zijn we zonder enige hulp van AMD of wie dan ook bij DX11 gekomen. En daarom vind ik het ook onzin om AMD de credits te gaan geven voor DX12. Die is echt niet samen met Windows 10 uit de lucht komen vallen omdat AMD met Mantle kwam.

[Madrox]

Je misleid jezelf door alleen maar te kijken naar de performance met sterke cpu's, die de inefficientie van DX11 toch wel erdoor drukken. Ten koste van veel meer cpu load en dus meer hitte en meer stroomverbruik. De cpu moet immers harder werken.

Games draaien wel degelijk beter; op systemen waar een zwakke cpu inzit. Dankzei Mantle/DX12 worden de gpu's daar beter belast en krijg je dus ook een betere performance.

http://www.anandtech.com/...w-amd-nvidia-star-swarm/3
Dit gaat eraan komen...

Gelijke of betere performance met minder cores of zwakkere cpu cores. Betere frame-times == smoother performance.

Bagataliseer dat maar. Feit is dat DX11 zijn beste tijd gehad heeft en we eigenlijk al die tijd onze hardware niet optimaal hebben kunnen benutten.

Je verwijst naar "goede games" , wat nergens op slaat; ook die moeten het doen met de beperkingen van DX11.

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[computerjunky]

Een serieuze gamer heeft wel zeer waarschijnlijk ook een krachtige cou naast zijn gpu en dus is de prestatiewinst voor mensen met een high end videokaart nihil.
De winst licht bij budget gamers met een goedkoop traag pctje.

ik heb een intel; 3770k die makkelijk op 4,6 ghz draait en heb echt helemaal niks aan de zogenaamde prestatiewinsten omdat die er zo goed als niet zijn.

[Madrox]

De echte winst komt pas met de volgende generatie dx12 games.

[Verwijderd]

http://www.anandtech.com/...w-amd-nvidia-star-swarm/3
Dit gaat eraan komen...

Tsja, Star Swarm is bewust suboptimale DX11-code, om Mantle te promoten.
Het raakt bewust aan alle zwakke punten in het DX11-ontwerp. Je ziet ook dat nVidia hier veel aan heeft verbeterd, en het stukken beter doet dan AMD in deze worst-case. In games zie je dat verschil echter niet of nauwelijks terug.

Verder, zwakke CPUs worden ook ieder jaar sneller, niet trager. Het probleem is nu al niet zo groot, en wordt alleen maar kleiner met de tijd.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[Madrox]

Sorry, ik speel hier geen Nvidia vs AMD spelletje. Zoals ik al laat zien, kan er nog veel meer uit de Geforce cores getrokken worden qua drwa calls. Onomstotelijk bewezen dat DX11 een grote bottleneck is, voor beide kampen. Voor de een gaat het dan om een factor 8, de ander nog veel meer. Het blijven aanzienlijke verbeteringen, in beide gevallen.

fyi; ik google naar DX12 performance, niet Mantle. dat ze die er naast zetten in de reviews, is niet zo gek. Maar is verder irrelevant aan de potentie van DX12.

Buiten dat; DX12 en Mantle komen niet zomaar uit de lucht vallen:

Developers have been asking for a thinner, more efficient API that allows them to control hardware resources more directly - See more at: http://blogs.nvidia.com/b...-12/#sthash.dOaBHw0V.dpuf

Developers? Ontwikkelaars! Game ontwikkelaars!

Het probleem is wel groot; je hebt nu sterkere videokaarten nodig om op een acceptabel niveau te komen. Je ben meer geld kwijt. Straks speel je je spellen al lekker met een mainstream videokaart en al met een dualcore, waarvoor je nu een quad nodig hebt en minsten een 280x of gtx970.

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Nature]

Wat je als laatste zegt doet me denken aan alchemisten in de middel eeuwen, zij zochten manieren om lood in goud te veranderen wat natuurlijk niet lukte.
Ik wacht benchmarks af, het zou leuk zijn als wat je zegt waarheid wordt, dan zou mijn GTX 970 evenveel power hebben als een Titan X of misschien wel 1,5

[Reactie gewijzigd door Nature op 22 juli 2024 14:38]

[Verwijderd]

Developers? Ontwikkelaars! Game ontwikkelaars!

Ik ben een developer, en ik heb er nooit om gevraagd, en vele collega's met mij.
Ik vind het vooral een hoop marketing-blaat, en weinig wol. In de praktijk win je hier en daar een paar procenten, tsja, leuk, maar meer ook niet.
Ik vind persoonlijk de nieuwe 12_1 features interessanter, want die maken het mogelijk om bepaalde algoritmen in realtime te implementeren, wat eerder nog niet mogelijk was.

je hebt nu sterkere videokaarten nodig om op een acceptabel niveau te komen.

Erm, dit klopt natuurlijk niet. Als de CPU/API de bottleneck is, dan helpt een sterkere videokaart ook niets.

[Verwijderd]

Oja, want bij AMD, Nvidia en zelfs Microsoft; het zijn allemaal leugenaars.

Ik zeg niet dat het leugenaars zijn. Ik zeg alleen dat het zwaar overtrokken is dat alle developers erom gevraagd zouden hebben. De meesten niet.

Het web staat er vol mee.

Grotendeels steeds hetzelfde kleine groepje van developers, die door AMD gesponsord werden ivm Mantle (DICE, Nixxes, Oxide).

Kom eens onder die steen vandaan, Scalibq.

Tsja, ik zou zeggen: kijk eens naar jezelf.
Kijk eens goed naar de bronnen, zoals ik hierboven zeg.
Zodra AMD met de eerste vage berichten kwam over een alternatief voor DX, had ik op m'n blog al geschreven dat een hardware-abstractielaag als DX een noodzakelijk kwaad is. Verschillende game-developers hebben ook op dat blog gereageerd, en waren het roerend met mij eens. Ook op Beyond3d liep er een dergelijke discussie.

Ehmm, je wil het maar niet snappen. Als je "zwakke" cpu de videokaart afremt kan je twee dingen doen; een nog sterkere videokaart erin proppen, waardoor de fps omhoog gaat(ja dat gebeurt echt, wederom niet optimaal maar toch)

De framerate kan alleen maar omhoog gaan als de CPU niet de bottleneck is. Ik snap het wel, maar ik ben bang dat jij het niet snapt.
Als de CPU de bottleneck is, dan haalt de GPU dus per definitie niet z'n maximale performance, en heeft het dus geen zin om een GPU erin te zetten met nog betere performance. De bottleneck is immers dat de CPU de commando's niet zo snel kan aanvoeren als dat de GPU ze kan verwerken.

[Madrox]

De framerate kan alleen maar omhoog gaan als de CPU niet de bottleneck is

Hoe verklaar je dit dan ?
http://www.tomshardware.c...-overclocking,3888-3.html
http://www.anandtech.com/...he-intel-pentium-g3258-ae
BF4
Gemiddelde fps GTX 770 + G3258 (4.7Ghz) = 56.3
Gemiddelde fps GTX Titan _ G3258 (4.5Ghz) = 77

Met tomb raider zie je precies hetzelfde, de Titan/G3258 combo zet veel hogere scores neer dan de GTX770+G3258. Scalibq, myth busted!

Ondanks de lagere overklok scoort de GTX Titan toch veel hoger. Conclusie, met een sterkere videokaart gaat de fps omhoog, ook met een relatief zwakkere cpu.

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

Hoe verklaar je dit dan ?

Wat moet er precies verklaard worden dan?
Je pakt hier twee random benchmarks van verschillende sites... Het is handig als je wat duidelijker formuleert wat je wil zeggen/vragen, en daarnaast is het niet verstandig om benchmarks van verschillende sites te vergelijken, want ze testen niet allemaal op dezelfde manier.
Afgezien daarvan lijkt me de meest logische verklaring dat dit geval niet CPU-limited is.
Hoewel je dat ook weer niet zomaar kunt zeggen, omdat je GPUs van verschillende architecturen vergelijkt, die dus niet per definitie dezelfde CPU-load hebben.
Het is allemaal veel te vaag.

Ondanks de lagere overklok scoort de GTX Titan toch veel hoger. Conclusie, met een sterkere videokaart gaat de fps omhoog, ook met een relatief zwakkere cpu.

Als je niet CPU-limited bent wel ja.
Of dacht je dat je met DX11 altijd per definitie CPU-limited was? Dan had je beter moeten opletten, ik zei namelijk net zelf al dat dat niet zo is, en DX11 lang niet zo slecht is als men je wil doen geloven.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[Madrox]

Beide benchmarks laten hetzelfde beeld zien; met een sterkere cpu is er meer fps performance; maw; de G3258 bottlenecked de GPU. Aan de andere kant weerleg ik tegelijkertijd jouw statement; Ook al is de cpu de bottleneck; met een krachtiger gpu krijg je toch meer perfornance. twee vliegen in 1 klap.

Het zijn idd random benchmarks, maar deels ook met dezelfde condities. Kan je helaas geen 1 unieke review/benchmark laten zien daar dit soor condities zelden/nooit getest worden. Beetje lullig om mij dan te verwijten dat ik daar niet mee kom. Leg echter verschillende reviews naast elkaar en je zal hetzelfde beeld zien. Als je dat wil zien tenminste. Iemand die er niet open voor staat zal altijd op zoek gaan naar rotte plekken en die uitvergroten, om maar achter zijn eigen gelijk te kunnen blijven staan.

[.oisyn]

Grotendeels steeds hetzelfde kleine groepje van developers, die door AMD gesponsord werden ivm Mantle (DICE, Nixxes, Oxide).

Dit is echt zo'n bullshit. Je ziet spoken. Het klopt dat Nixxes in het verleden is gesponsord door AMD, en dat er daarom intern Mantle implementaties zijn ontwikkeld voor diverse games. Maar dat heeft geen ene reet te maken met de vraag om een lagere overhead van de D3D API. Correlatie impliceert geen causatie.

Bottom line is dat wij weten wat op consoles mogelijk is, en dat de PC daar doorgaans ver op achter loopt, en flink moeite moet gaan zitten doen om draw calls bij elkaar te gaan zitten batchen terwijl dat eigenlijk niet nodig zou hoeven zijn als de API gewoon wat lichter was. Gelukkig komt daar met DirectX 12 enigszins verandering in. En natuurlijk is het geen heilige graal, maar het is weldegelijk fijn om zelf in controle te zijn over state changes en resource management, omdat je daar vanuit de game veel meer kennis over hebt dan de API die dat maar just in time moet uitvogelen aan de hand van de calls die je doet.

Het is weldegelijk iets waar veel gamedevelopers om vragen (of iig in het verleden om vroegen, want het probleem is tegenwoordig een stuk minder groot dan vroeger). En absoluut niet alleen degene die gesponsord worden door AMD. Je begint echt te klinken als een alu-hoedje consiparacy theorist, en je vernietigd daarmee je eigen geloofwaardigheid.

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:38]

[Verwijderd]

Maar dat heeft geen ene reet te maken met de vraag om een lagere overhead van de D3D API. Correlatie impliceert geen causatie.

Als jij bronnen geeft waaruit dat blijkt, dan zou je het misschien kunnen bewijzen. Tot die tijd zijn er vooral bronnen die ik genoemd heb (Beyond3D, discussie op mijn blog) waaruit het tegengestelde blijkt.

Bottom line is dat wij weten wat op consoles mogelijk is, en dat de PC daar doorgaans ver op achter loopt, en flink moeite moet gaan zitten doen om draw calls bij elkaar te gaan zitten batchen terwijl dat eigenlijk niet nodig zou hoeven zijn als de API gewoon wat lichter was.

Tsja, ik heb dat jaren geleden in mijn blog al behandeld.
TL;DR:
1) Hardware-abstractie op een PC is een noodzakelijk kwaad vanwege de brede selectie aan hardware.
2) Console-devs zien spoken, want PCs hebben sowieso veel snellere CPUs dan consoles, dus het valt in de praktijk allemaal wel mee.
3) In DX10 en DX11 heeft MS al aardig wat stappen gezet om meer te doen met minder draw calls, en om verwerking over meerdere threads te verdelen etc. De CPU-overhead is niet meer zo'n probleem als het ooit was.
Dit is overigens bij de introductie van DX11 ook nog door AMD geroepen: https://web.archive.org/w...excited-about-directx-11/

3. DirectX has been sliced and diced and the internals redesigned to ensure that it is much more efficient at using the horsepower present in multiple CPU cores.

Daar is later nog bijgekomen:
4) Zie je wel, Mantle zet ook nauwelijks zoden aan de dijk. Precies de 10-15% die ik jaren daarvoor al voorspelde, op een beetje gangbaar i5/i7 game-systeem.
Blijkbaar kon ik de overhead in DX11 prima inschatten.

(of iig in het verleden om vroegen, want het probleem is tegenwoordig een stuk minder groot dan vroeger).

Dat is dus ook precies wat ik in mijn blog zei.

Je begint echt te klinken als een alu-hoedje consiparacy theorist, en je vernietigd daarmee je eigen geloofwaardigheid.

Jij werkt voor Nixxes, en valt kennelijk over deze post van mij. Ik denk dat je eerder bewijs levert dat jij idd Mantle/DX12 loopt te promoten.
In feite zeg je niets anders dan ik, behalve dat je zonder onderbouwing claimt dat devs erom gevraagd hebben (en mij persoonlijk aanvalt, met je alu-hoedje-opmerking). Wat in jouw geval dus niet geloofwaardig is, omdat jij zelf tot het groepje devs behoort die onder AMD vallen, zoals ik al zei.
Je had beter niet kunnen reageren.

[.oisyn]

Als jij bronnen geeft waaruit dat blijkt, dan zou je het misschien kunnen bewijzen. Tot die tijd zijn er vooral bronnen die ik genoemd heb (Beyond3D, discussie op mijn blog) waaruit het tegengestelde blijkt.

Dat is vooral een nuanceverschil. Ik heb je blogs ook gelezen. Wat jij vooral lijkt te doen is wat er gezegd wordt in het extreme trekken, daar een ontzettend genuanceerd verhaal tegenover zet waar je bijna wel eens mee moet zijn, en de bijval die je krijgt vervolgens gebruikt als bevestiging dat het allemaal maar onzin is, terwijl dat wat er gezegd is eigenlijk gewoon verkeerd wordt geinterpreteerd.

Fact of the matter is dat ik de verhalen al hoorde voordat ik bij Nixxes werkte, en toen ik hier begon in 2004 het pijnlijk duidelijk was dat de PC een probleem had. AMD sponsoring kwam pas voor het eerst met Deus Ex: Human Revolution, in 2011.

1) Hardware-abstractie op een PC is een noodzakelijk kwaad vanwege de brede selectie aan hardware.

Dit is het perfecte voorbeeld van wat ik hierboven zeg. Niemand beweert dat de PC geen HAL moet hebben, of dat je geen prijs zou moeten betalen voor die HAL. Ik kan me een alinea in je blog herinneren waar je in gaat op verhaal van een lead developer van een studio die zogenaamd vroeg of we de API niet gewoon weg konden doen. De werkelijkheid was (en das ook duidelijk in je in je blog aangehaalde bron te lezen) dat het een artist was die tegen een developer iets had gezegd als "kunnen we dan niet gewoon zonder API werken" toen hij erachter kwam dat draw calls op de PC een stuk duurder zijn dan op de console. Ik kan me een dergelijke situatie perfect voortellen - artists zijn over het algemeen nou niet echt de meest technologisch onderlegde mensen (dat is hun baan ook niet), en het was helemaal niet de bedoeling van de developer in kwestie om te suggereren dat de API inderdaad weg moest - het was gewoon een situatieschets. Desalniettemin ging jij er vol op in door te zeggen dat dat natuurlijk complete onzin was. Ja, dat wist die developer ook wel.

Waar het om gaat is dat DX conceptueel gewoon inefficient is opgezet en geïmplementeerd, los van de hardware features die je exposed. Optimalisaties die gedaan worden door drivers moeten just-in-time op de draw call, want eerder is niet alle informatie bekend. Dat maakt de API gewoon conceptueel flawed. Je stelt allerlei states in met Set* calls, maar die individuele states en resources die je bind zeggen op zichzelf niet zoveel. Het krijgt pas betekenis als je ze allemaal bij elkaar ziet, en die informatie is pas definitief als je de uiteindelijke draw doet. Pas dán kan de driver shaders gaan optimizen en patchen aan de hand van vertex declarations en static constants. En dan heb ik het nog niet eens over de geïmpliceerde overhead die bij dat design komt kijken: bij de eerstvolgende draw na elke state change zal de implementatie een lookup moeten doen van de huidig ingestelde resources en dergelijke, zodat hij het juiste gecachede voorwerk erbij kan vinden (middels hash tables of een andere geassocieerde datastructuren). Al die logic maakt een draw call gewoonweg duur, en dat was niet nodig geweest als ze van begin af aan gewoon state objects hadden gehad. Let wel, dit heeft compleet niets te maken met hardware features en architectuur - dit is gewoonweg API design, en dat had bij wijze van spreken in Direct3D8 al zo kunnen werken.

2) Console-devs zien spoken, want PCs hebben sowieso veel snellere CPUs dan consoles, dus het valt in de praktijk allemaal wel mee.

Zoals ik daarnet al zei, eigenlijk is het gewoon te laat. Ik had changes zoals bovenstaande liever 10 jaar geleden gezien. Computation power is een stuk harder gegroeid dan het aantal draw calls dat per frame gedaan wordt (omdat die laatste niet lineair schaalt met scene complexiteit), dus relatief gezien is de D3D overhead steeds minder geworden. Desalniettemin ben ik blij dat de verandering er wel is. En dan geef ik niets om "meer FPS!!!11", maar simpelweg meer tijd op de CPU om te besteden aan andere zaken. Het is niet dat omdat de CPU's tegenwoordig snel genoeg zijn dat dingen niet optimaal hoeven te zijn. Verwacht alleen geen gouden bergen.

Jij werkt voor Nixxes, en valt kennelijk over deze post van mij.

Natuurlijk, je bent al jaren Nixxes medewerkers aan het uitfoeteren om hun zogenaamde "AMD bril". Dat zijn echter geen feiten, en de waarheid is anders. Ik heb je al meerdere keren verteld dat het gewoon niet waar is, maar goed, wie ben ik, je hebt me inmiddels wel duidelijk gemaakt dat je jezelf veel intelligenter vindt.

omdat jij zelf tot het groepje devs behoort die onder AMD vallen

Voor zover ik weet was Thief 4 de laatste deal met AMD. Nixxes is nu vooral bezig met Rise of the Tomb Raider voor Xbox 360. Overigens heb ik in mijn hele Nixxes carriere nog nooit direct op een project gezeten dat is gesponsord door AMD, ik werk vooral op de consoles.

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:38]

[Verwijderd]

Dat is vooral een nuanceverschil. Ik heb je blogs ook gelezen. Wat jij vooral lijkt te doen is wat er gezegd wordt in het extreme trekken

Nee, dat heeft Richard Huddy (marketing van AMD) vooral gedaan. Die kwam met een statement van "make the API go away". En dat nuanceerde ik uiteraard, want zoals ik zeg, enige hardware-abstractie is een noodzakelijk kwaad op de PC.
Achteraf bleek Mantle toch ook eigenlijk wel een API te zijn, en iets van een abstractielaag, dus bleken Huddy's claims onzin, zoals ik al eerder aanstipte.

Fact of the matter is dat ik de verhalen al hoorde voordat ik bij Nixxes werkte, en toen ik hier begon in 2004 het pijnlijk duidelijk was dat de PC een probleem had.

Tsja, dat het probleem er was, is al heel lang bekend. Wie kent niet de nVidia-presentatie "Batch, Batch, Batch"?
http://www.nvidia.com/docs/IO/8228/BatchBatchBatch.pdf
Dat is nog wel van voor 2004 overigens. Maargoed, jij draait nog niet zo lang mee als ik, natuurlijk.
Het punt is dus dat MS in die jaren niet heeft stilgezeten, en dat de problemen toch op vele manieren wel zijn aangepakt door de jaren, terwijl veel developers nog steeds praten alsof het 2002 is.

Dit is het perfecte voorbeeld van wat ik hierboven zeg. Niemand beweert dat de PC geen HAL moet hebben, of dat je geen prijs zou moeten betalen voor die HAL.

Richard Huddy beweerde dat dus *wel*.

Ik kan me een alinea in je blog herinneren waar je in gaat op verhaal van een lead developer van een studio die zogenaamd vroeg of we de API niet gewoon weg konden doen.

Nee, dat was Johan Andersson, en Huddy was degene die dat op die manier parafraseerde. Ik heb Andersson gevraagd om een reactie hierop, en hij wilde nooit bevestigen dat hij dat inderdaad gezegd heeft. Het lijkt er dus op dat Huddy in de naam van AMD marketing het verhaal van Andersson enigszins uit het verband heeft getrokken.
En daar reageerde ik dus op.

Ja, dat wist die developer ook wel.

Ik heb dan ook nooit gezegd dat Andersson dat niet zou weten. Maar Huddy is een ander verhaal. Sterker nog, Huddy heeft later nog gereageerd op mijn blog, maar nooit de vragen beantwoord die ik neerlegde bij het opgeven van een API. Ook Andrew Copland reageerde hierop, en was het met mij eens dat Huddy wel wat had uit te leggen als je de API geheel zou verwijderen.

Het krijgt pas betekenis als je ze allemaal bij elkaar ziet, en die informatie is pas definitief als je de uiteindelijke draw doet. Pas dán kan de driver shaders gaan optimizen en patchen aan de hand van vertex declarations en static constants.

Wat jij bij dit verhaal altijd vergeet, is dat de manier waarop de driver de informatie moet verwerken en de GPU moet aansturen, afhankelijk is van hoe deze GPU in elkaar zit. Er zitten hier al behoorlijke verschillen tussen nVidia, AMD en Intel (bij de een zet je een bepaalde waarde gewoon in een registertje, bij de ander moet het een instructie zijn in de command stream etc) bij dezelfde generatie, en dan hebben we het nog niet over verschillende generaties.
In vroeger tijden ging jouw verhaal helemaal niet op. De GPUs waren gewoon grotendeels state machines, waarbij de meeste states ook inderdaad direct gezet konden worden in de hardware. Vandaar dat OpenGL en D3D dus op die manier waren opgezet.

Pas bij DX10-hardware, toen we oa overgingen op unified shaders en GPGPU-ondersteuning, zijn GPUs compleet anders van opzet geworden. Probleem hierbij was dat Microsoft met DX10/11 toch ook de oudere GPUs wilde ondersteunen, want je kunt de DX9-hardware niet zomaar in de kou laten staan.
Maargoed, jij draait nog niet zo lang mee, dus dat kun jij allemaal niet weten. Het zou je echter sieren als je op z'n minst onderkende dat er bij jou daar een kennisgat is, ipv dat je zo alwetend doet, en je verhaal als de absolute, altijd geldende waarheid presenteert.

Let wel, dit heeft compleet niets te maken met hardware features en architectuur - dit is gewoonweg API design, en dat had bij wijze van spreken in Direct3D8 al zo kunnen werken.

Dit is dus ten eerste niet waar. Jij denkt blijkbaar dat alle shader-hardware hetzelfde is. Nee, D3D8 hardware kun je sowieso nauwelijks echt shaders noemen, de pixelshaders zijn meer een geavanceerde vorm van register combiners.
Daarnaast moest D3D8 ook nog op DX6/DX7-hardware draaien, net als dat DX11 ook nog op DX9-hardware moest draaien.

Natuurlijk, je bent al jaren Nixxes medewerkers aan het uitfoeteren om hun zogenaamde "AMD bril".

Helemaal niet. Met Tim heb ik altijd interessante gesprekken. De rest spreek ik niet vaak. Jij bent de enige die altijd zo'n geldingsdrang heeft, en altijd met die blaatverhalen komt.
Dit is ook weer een beetje jammer. Ten eerste klopt je hele verhaal over mijn blog niet (ik heb sowieso nooit over een designer gesproken, dat is compleet je eigen fantasie... vast ook de reden dat je niet met daadwerkelijke quotes en links komt waar dat op mijn blog zou staan, want dat staat er niet). Ten tweede schiet ook je technische verhaal enorm tekort. Jammer.

Je doet me een beetje denken aan de gemiddelde linux-gebruiker. Omdat ze een beetje een idee hebben van hoe linux werkt, denken ze meteen dat ze een expert zijn op alle OSen, nieuw en oud.
Jij hebt ook een beetje info van hoe moderne AMD-GPUs werken, en daarmee generaliseer je alle GPUs uit de hele geschiedenis, van alle vendors. Zo werkt het natuurlijk niet.
Maar iedereen met een beetje gezond verstand begrijpt dat natuurlijk ook wel. Jouw bewering komt in feite neer op dat GPUs al sinds D3D8 op dezelfde manier zouden werken (we spreken 1999), en dat nu (in 2015) ineens de graphics-industrie wakker wordt (mensen bij MS, Khronos, AMD, Intel en nVidia die er veel meer verstand van hebben dan jij), en APIs op een andere manier gaat ontwerpen, want "Oh ja, duh, we hebben het al die jaren compleet verkeerd zitten doen!".
Wat denk je zelf?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[.oisyn]

.. Verhaal over Hudde en Andersson..

Dan heb ik dat verkeerd onthouden, excuses.

Dat is nog wel van voor 2004 overigens. Maargoed, jij draait nog niet zo lang mee als ik, natuurlijk.

Oh please, jij bent ook maar een jaar of 5 ouder dan ik. En natuurlijk ken ik die presentatie.

Het punt is dus dat MS in die jaren niet heeft stilgezeten, en dat de problemen toch op vele manieren wel zijn aangepakt door de jaren, terwijl veel developers nog steeds praten alsof het 2002 is.

Het werd ons anders in 2008 nog eens pijnlijk duidelijk in Tomb Raider: Underworld, dat geplaagd werd door stalls op nVidia hardware door hun shader patching. DirectX9 tijdperk overigens.

. Probleem hierbij was dat Microsoft met DX10/11 toch ook de oudere GPUs wilde ondersteunen, want je kunt de DX9-hardware niet zomaar in de kou laten staan.

Je komt wel vaker met dat verhaal, maar dat ontkracht helemaal niet wat ik zeg. Jij zal als software developer toch ook wel in moeten kunnen zien dat een interface met state objects prima is te implementeren op de oude manier. In plaats van allerlei driverwerk in de finalization van een state object, stel je alle resources gewoonweg in op de oude manier. Backward-compatibility heeft er dus geen zier mee te maken.

Jij denkt blijkbaar dat alle shader-hardware hetzelfde is

Grappig dat je dat kunt afleiden uit mijn tekst. Nee, dat denk ik helemaal niet. Ik weet zelfs dat dat niet het geval is.

Nee, D3D8 hardware kun je sowieso nauwelijks echt shaders noemen, de pixelshaders zijn meer een geavanceerde vorm van register combiners.

Ik zei dan ook "bij wijze van spreken". Ik zei niet dat het in het D3D8 tijdperk ook zinnig was geweest. In D3D9 echter wel.

Daarnaast moest D3D8 ook nog op DX6/DX7-hardware draaien, net als dat DX11 ook nog op DX9-hardware moest draaien.

Irrelevant, zie boven.

Het zou je echter sieren als je op z'n minst onderkende dat er bij jou daar een kennisgat is

Tja kijk, ons leeftijdsverschil is helemaal niet zo groot, en daarna draai ik al een stukje langer mee dan sinds ik bij Nixxes begonnen ben. Bovendien heb jij zo goed als geen ervaring op de consoles, noch met daadwerkelijke gamedevelopment. Ik heb nog een ontzettende onzinquote van jou in mijn DM staan waarin je stelt dat 1k draw calls per frame extreem veel is vandaag de dag. Dat is gewoon quatsch . Je zit er minstens een factor 10 naast. Rise of the Tomb Raider doet er ongeveer 17k. Over leven in 2002 gesproken...

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:38]

[Verwijderd]

Oh please, jij bent ook maar een jaar of 5 ouder dan ik.

Het gaat niet alleen om leeftijd natuurlijk.
Ik ben al heel vroeg begonnen met programmeren, en heb alles vanaf 8-bit en software-rendering tot aan nu bewust meegemaakt.
Ik heb met alle versies van D3D gewerkt, en ook met vendor-APIs daarvoor/daarnaast.
Volgens mij ben jij pas ergens rond D3D9 ingestapt.

Het werd ons anders in 2008 nog eens pijnlijk duidelijk in Tomb Raider: Underworld, dat geplaagd werd door stalls op nVidia hardware door hun shader patching. DirectX9 tijdperk overigens.

DX9 is uit 2002, in 2008 was DX10.1 er al.
Het argument dat een API uit 2002 niet ideaal is in 2008 is niet zo sterk natuurlijk.

Je komt wel vaker met dat verhaal, maar dat ontkracht helemaal niet wat ik zeg. Jij zal als software developer toch ook wel in moeten kunnen zien dat een interface met state objects prima is te implementeren op de oude manier. In plaats van allerlei driverwerk in de finalization van een state object, stel je alle resources gewoonweg in op de oude manier. Backward-compatibility heeft er dus geen zier mee te maken.

Nee, het gaat echter om forward compatibility. Zoals hierboven: je haalt een API uit 2002 aan, waarbij je blijkbaar verwacht dat die optimaal kan omgaan met hardware uit 2008.
Je bekijkt het probleem dus precies van de verkeerde kant. Zoals ik al zei, in het DX10-tijdperk werden GPUs compleet anders ontworpen.
Nogal logisch dat de DX9-API daar geen rekening mee kon houden.

Ik zei dan ook "bij wijze van spreken". Ik zei niet dat het in het D3D8 tijdperk ook zinnig was geweest. In D3D9 echter wel.

Nee. Maar dat komt wsch omdat je pas later in het D3D-tijdperk bent ingestapt. Er is in de jaren van D3D9 nogal wat veranderd qua GPUs (mede doordat DX9 ook nog een tijd ondersteund bleef toen er al DX10-kaarten op de markt waren, zoals je zelf onbewust met je voorbeeld uit 2008 aanhaalt).
Net als met DX11 overigens. De Radeon 5000s zijn ook compleet anders dan de latere GCN-GPUs.
GCN kan wel met DX12 omgaan, de oudere GPUs niet. Die architectuur is op veel punten compleet anders.

Jammer maar helaasch.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[.oisyn]

Ik ben al heel vroeg begonnen met programmeren

Same here, ik was 8 toen ik begron te prutsen met GWBasic.

Volgens mij ben jij pas ergens rond D3D9 ingestapt.

D3D5 actually, in '98. En heb ook wat met Glide gespeeld. En natuurlijk mijn fair share van software renderers geïmplementeerd.

Het argument dat een API uit 2002 niet ideaal is in 2008 is niet zo sterk natuurlijk.

Fair enough, mijn geheugen liet me wat in de steek.

Zoals ik al zei, in het DX10-tijdperk werden GPUs compleet anders ontworpen. Nogal logisch dat de DX9-API daar geen rekening mee kon houden

Prima, dan stel ik dat D3D10 zo had kunnen werken. Dat deed het niet. Jouw bewering is dat dat niet kon om backwards compatibility. Dat vind ik een onzin-stelling om redenen die ik al uiteen heb gezet.

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:38]

[Verwijderd]

D3D5 actually, in '98. En heb ook wat met Glide gespeeld. En natuurlijk mijn fair share van software renderers geïmplementeerd.

Tsja, de uitdaging ligt er, zoals je weet: Maak maar een betere 8088+CGA demo.
Ik heb nog nooit iets met software rendering van je gezien, dus ik zou graag bewijs zien dat je niet alleen weet wat het is, maar dat je ook daadwerkelijk de skills hebt om een redelijk robuuste en goed geoptimaliseerde renderer te bouwen.
Kun je dat niet, dan vind ik niet echt dat je recht van spreken hebt over API-design, CPU-optimalisaties, de interne werking van GPUs etc. Want als je het zelf niet kunt bouwen, wat is jouw mening erover dan nog waard?

Prima, dan stel ik dat D3D10 zo had kunnen werken. Dat deed het niet. Jouw bewering is dat dat niet kon om backwards compatibility. Dat vind ik een onzin-stelling om redenen die ik al uiteen heb gezet.

Dan zijn we het oneens, meer niet (al weet ik niet aan welke redenen je hier precies zou refereren).
Want ik zie duidelijk backward compatibility in de vorm van downlevel modes (die weliswaar in DX10 nog niet geimplementeerd waren, al kon je ze al wel vinden in de SDK, maar in DX11 werkten ze wel, en zoals je weet is DX11 qua design niet anders dan DX10).
Dus, ja, als je dat verwerpt, dan zou je kunnen stellen dat DX10 specifiek geoptimaliseerd kon worden voor DX10+-hardware, en dan had het er iets anders uit kunnen zien (al zou je nog een paar jaar moeten wachten voordat je bepaalde features van DX12 zou kunnen opnemen, zoals async shaders. In de DX10-tijd stond GPGPU nog in de kinderschoenen, en pas in DX11 kwam er uberhaupt support voor compute shaders).
Maar als je dat niet verwerpt, dan geef je me dus gelijk.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[.oisyn]

Tsja, de uitdaging ligt er, zoals je weet: Maak maar een betere 8088+CGA demo.

Dat doet dus echt compleet niet terzake . Blijkbaar wil je vooral bevestiging zien van de lengte van je eigen e-penis. De tijd om bezig te zijn met nutteloze zut is inmiddels wel voorbij, met een tweede kind op komst en een nieuwbouwhuis waar we net 2 maanden in wonen.

maar dat je ook daadwerkelijk de skills hebt om een redelijk robuuste en goed geoptimaliseerde renderer te bouwen.

Tja, ik zou graag wat laten zien, helaas ben ik jaren aan programmeerwerk kwijtgeraakt tijdens een HDD crash in 2013.
Ik heb nog wel een HTML4/JS implementatie van een raycaster voor je: http://oisyn.nl/wolfjs/

al weet ik niet aan welke redenen je hier precies zou refereren

Dit stukje:

Jij zal als software developer toch ook wel in moeten kunnen zien dat een interface met state objects prima is te implementeren op de oude manier. In plaats van allerlei driverwerk in de finalization van een state object, stel je alle resources gewoonweg in op de oude manier. Backward-compatibility heeft er dus geen zier mee te maken.

[Verwijderd]

Dat doet dus echt compleet niet terzake .

Natuurlijk wel. Het verschil tussen theorie en praktijk is dat je voor ieder systeem apart moet bedenken wat de meest optimale manier is om iets te renderen (precies zoals ik dus aangeef met verschillen in GPU-architecturen).
Zo'n 8088+CGA-renderer zit weer compleet anders in elkaar dan hoe je het op EGA of VGA zou doen, of met een ander type CPU.

Ik zie bij jou nergens enig besef hiervan. Jij scheert alles over 1 kam. En dat lijkt mij te duiden op een gebrek aan inzicht en ervaring. Wat dus blijkt, want je kunt en wilt niets laten zien dat het tegendeel bewijst.

De tijd om bezig te zijn met nutteloze zut is inmiddels wel voorbij, met een tweede kind op komst en een nieuwbouwhuis waar we net 2 maanden in wonen.

Tsja, alsof wij geen baan en leven zouden hebben.
Maarja, het zal jou wsch gewoon veel meer moeite kosten dan ons, als je het uberhaupt al kunt.

Ik heb nog wel een HTML4/JS implementatie van een raycaster voor je: http://oisyn.nl/wolfjs/

Tsja, dat dekt niet echt de lading.

Dit stukje:

Ja, dat had ik dus al weerlegd door te wijzen op het feit dat je niet van een API uit 2002 kunt verwachten dat die optimaal aansluit op hardware uit 2008.
Een API uit 2008 die backwards compatible is met hardware uit 2002 kan wel, maar dat zien we dus ook.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[.oisyn]

Natuurlijk wel. Het verschil tussen theorie en praktijk is dat je voor ieder systeem apart moet bedenken wat de meest optimale manier is om iets te renderen

Goh, wat denk je dat mijn werk is? Ik implementeer renderers voor tal van verschillende consoles, en daarnaast waren er ook nog eens verschillende codepaden voor verschillende soorten GPU's in het D3D9 tijdperk.

Momenteel ben ik vooral bezig met low-level CPU optimizations voor de PPC in de Xbox 360, zoals het voorkomen van L2 cache misses dmv prefetches en het omschrijven van integer, FPU en Altivec instructies om load-hit-stores te voorkomen. Issues waar een x86 bijvoorbeeld totaal geen last van heeft (die verdomd goed is in het predicten van memory access patterns en LHS sowieso geen betekenis heeft)

De notie dat ik geen verstand zou hebben van variatie in hardware is compleet uit te lucht gegrepen.

Tsja, alsof wij geen baan en leven zouden hebben.

Bij jou vraag ik me dat serieus af ja . Maar eigenlijk is dat niet zo relevant, ik zeg alleen maar dat ík de zin en tijd niet kan opbrengen om met zaken bezig te zijn alleen maar om iets voor jou te bewijzen. Jij hebt geen enkele vorm van betekenis in mijn leven, dus daar ga ik ook geen tijd aan wasteren. Mijn peers weten wat ze van mij kunnen verwachten, dat is genoeg. De geldingsdrang is iets dat vooral in jouw hoofd leeft, gezien het feit dat je er keer op keer weer mee komt. Is het niet leeftijd, dan wel intelligentie of opleiding. Alles om voor jezelf te bevestigen dat je vooral beter ben dan ik. Terwijl je me eigenlijk helemaal niet kent en puur afgaat op wat internetposts. En dat mensen IRL anders zijn dan in het echt zou jij toch echt moeten weten, waar je door mensen die jou kennen vooral wordt omschreven als timide IRL en een ontzettende blaaskaak online (Tim's woorden).

Ja, dat had ik dus al weerlegd door te wijzen op het feit dat je niet van een API uit 2002 kunt verwachten dat die optimaal aansluit op hardware uit 2008.

Omdat we het eerst over D3D9 hadden, terwijl we het over D3D10 zouden moeten hebben. Edoch heeft D3D10 niet de door mij gesuggereerde state objects, wat gewoon had gekund zonder te breken met backwards compatibilty.

[Reactie gewijzigd door .oisyn op 22 juli 2024 14:38]

[Verwijderd]

Goh, wat denk je dat mijn werk is? Ik implementeer renderers voor tal van verschillende consoles, en daarnaast waren er ook nog eens verschillende codepaden voor verschillende soorten GPU's in het D3D9 tijdperk.

Ja, daaraan kan ik niet afleiden wat jij nu precies gedaan hebt eraan, en wat je er zelf van begrepen hebt, en in hoeverre het ontwerp van je eigen hand is, of hoe optimaal jouw bijdrage aan de code nu is.

De notie dat ik hier geen verstand van zou hebben is compleet uit te lucht gegrepen.

Nee hoor, dat komt omdat je in de jaren dat ik je ken eigenlijk nooit veel dingen hebt gezegd die echt veel hout sneden, of een dieper inzicht in de materie demonstreerden.

Omdat we het eerst over D3D9 hadden, terwijl we het over D3D10 zouden moeten hebben. Edoch heeft D3D10 niet de door mij gesuggereerde state objects, wat gewoon had gekund zonder te breken met backwards compatibilty.

Tsja, dit is dus weer onzin.
DX9 heeft uberhaupt geen state-objects. DX10 heeft per onderdeel van de pipeline een state-object, wat dus al een hele grote stap is richting het model dat jij suggereert. En gezien de hardware van die tijd (we spreken 2006), is de keuze van DX10 zeker niet suboptimaal.
Dat jij dan weer de fout maakt om het tegen hardware van 2010+ aan te leggen, daar hadden we het al over gehad.

Dus ja, ik blijf maar dingen zien die me doen concluderen dat je de materie niet volledig beheerst. Misschien kom je daar op je werk mee weg, omdat daar mensen als Tim rondlopen, die je handje vast kunnen houden waar nodig. Maar hier moet je het zelf doen, en dat gaat je niet zo best af.

De geldingsdrang is iets dat vooral in jouw hoofd leeft, gezien het feit dat je er keer op keer weer mee komt.

Grappig, jij bent toch keer op keer degene die op mij reageert en wel even denkt te weten hoe het allemaal zit. Zo ook hier. Het is duidelijk dat jij hier de aanval zoekt, en dat jij je wil bewijzen. Dat moet je echter wel met daden doen, niet met woorden.
Geen daden? Reageer dan ook niet meer op mij. En al HELEMAAL niet door dingen te roepen die in mijn blog zouden staan, terwijl dat pertinent onwaar is, alleen maar om mij persoonlijk aan te vallen.

In tegenstelling tot jou beweer ik ook niet dat ik jou ken, maar beperk ik me slechts tot de inhoud van jouw posts, waar je dus steeds met allerlei verhalen aankomt waarin je dingen denkt te moeten uitleggen aan mij, waar aantoonbare onjuistheden in staan, gecombineerd met persoonlijke aanvallen. Precies datgene dat ik ook beschrijf met 'geldingsdrang'.
Dat moet je bij mij niet doen, want als je me uitdaagt, neem ik die uitdaging aan. Dat is geen 'blaaskaakgedrag', want jij bent de blaaskaak. Wat ik doe is meer 'calling your bluff', en dat kun jij niet hebben, want je weet dat jij het niet waar kunt maken. Ik wel, want ik bluf niet. Vandaar dat ik dit soort uitdagingen graag aanneem van mensen als jij.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[.oisyn]

Zie verder de edits in mijn vorige post, en daar laat ik het bij.

[batjes]

Let wel dat DX tot 11 prop vol zat met stapels backwards compatible functies. Daarnaast bevat DX (net als de AMD/Nvidia drivers) een heleboel safety nets voor brakke programmeurs.
Allemaal overhead, wat nu (vrijwel) allemaal ook weg is.

Paar blogs gingen er wat dieper op in (heb zo de links niet), maar waren ook voorbeelden van functies wat in DX11 tiental(len) cpu cycles kostte, kost dat met DX12 nog maar enkele.

[Verwijderd]

Let wel dat DX tot 11 prop vol zat met stapels backwards compatible functies.

Ja, DX11 was geen nieuwe API, maar slechts een uitbreiding op DX10. Daarnaast is DX11 zo ontworpen dat ook DX9-klasse hardware nog ondersteund kan worden (dit was in DX10 niet het geval, al was dat wsch wel oorspronkelijk de bedoeling van MS).

[.oisyn]

Ofwel, DX12 doet minder dan DX11 waardoor de game zelf meer zal moeten doen. Dit klinkt mij als broekzak vestzak

Dat is het niet. Integenstelling tot de API, de game wél wat hij aan het doen is en wat er getracked moet worden. Sterker nog, een typische game doet dergelijke tracking op hoger niveau al.

[Verwijderd]

Nee toch, loopt Edge nu alweer achter? Ze kunnen net Chrome en Firefox bijhouden. Ik dacht dat Edge die zou moeten verslaan volgens Microsoft? Maar in veel gevallen is hij trager en bij de rest evenaart het nét. Plus minder ondersteuning. Pff, alweer de zoveelste tegenvaller van Microsoft icm browsers.

[Verwijderd]

Deze test zijn vaak alleen maar gemaakt om javascript performance te testen. Een browser is alleen meer dan een javascript environment. Hoe snel word netwerken afgehandeld, hoe snel word ssl afgehandeld, hoe snel word een dom three gecreëerd, hoe lang duurt het voordat css berekent is? Dit zijn dingen die vaak niet getest (kunnen) worden.

Door een gebruiker word snelheid op een nog andere manier bekeken, hoe lang duurt het voordat ik iets op het scherm zie en hoe snel kan ik scrollen zonder lags? Je kunt nog zo snel je javascript uitvoeren, de beste networking, etc hebben, maar als drawing langzaam gaat, ervaart een gebruiker de browser als sloom.

Deze test zeggen iets over de interne snelheid, maar mij zeggen ze niks omdat ik (net als veel andere mensen) snelheid meet in hoe snel zie ik iets en hoe responsive is een site met de browser.

[Blokker_1999]

Wat is achter lopen? En nu doe je net alsof de concurentie bij elke release grote stappen vooruit zet op gebied van snelheid. De tijd dat je eenvoudig veel snelheid kon winnen licht achter ons, het is rommellen in de marge. Uiteindelijk merk je het als eindgebruiker amper of niet.

[Luuk1983]

Het is juist heel knap dat ze met een nèt nieuwe browser al zo ver zijn dat Chrome en Firefox bijgehouden kunnen worden op een aantal vlakken. Met wat verdere Tweaking en een paar updates zou Edge misschien zelfs wel beter kunnen worden (met de nadruk op 'zou'). Sowieso is het een welkome verbeteren t.o.v. IE waardoor mensen die geen andere browsers gebruiken nu een snellere browser hebben dan voorheen.

[drakiesoft]

Die test zeggen helemaal niets. Bij dagelijks gebruik is IE sneller dan Chrome en Edge nu nog veel sneller.

[Esumontere]

Lol, hoelang heb je dat naast elkaar gedraaid? Waar heb je die info vandaan? IE is voelt naar mijn mening in het dagelijks gebruik juist extreem traag, vergeleken met welke third-party browser dan ook.

[Reactie gewijzigd door Esumontere op 22 juli 2024 14:38]

[batjes]

Zijn info in twijfel trekken en dan zelf met twijfelachtige info komen. Juistem.

IE11 gaat vandaag de dag nog goed mee op de render snelheid van de webpagina's. Heb FX, Chrome, Canary, Chromium, Palemoon, IE en Edge nu geinstalleerd staan, en de op het oog merkbare verschillen zijn echt minimaal.

IE is ondertussen al 2 jaar oud en Edge is net 2 dagen oud, best netjes dat deze browsers zo goed meekomen -op een Webkit georiënteerde www-.

Zelf ga ik voor IE/Edge voornamelijk i.v.m. hun betere hardware versnelling en font rendering.

[Esumontere]

Goed, dat was inderdaad niet helemaal netjes. Wat ik vooral bedoel is dat mijn ervaring op mijn toch behoorlijk snelle systeem (i5 4670, 8GB RAM) het opstarten, laden van tabs en de pagina-laadtijden enorm log en traag aanvoelen. Ik gebruik zelf Waterfox (64bits build van Firefox) en die voelt echt héél veel sneller aan.

[batjes]

Is ook afhankelijk van hoe vaak je het gebruikt, Als ik enkele dagen veel Palemoon gebruik en IE dan juist niet, is Palemoon vlotter met opstarten omdat Windows Palemoon dan prefetched i.p.v. IE/Edge.

Gebruik zelf Palemoon en Chrome Canary regelmatig ivm netflix en ze zitten alle 3 in mijn prefetch en ik zie echt amper verschil (behalve dat Edge sneller lijkt op te starten, maar die gebruik ik regelmatiger)

[Reactie gewijzigd door batjes op 22 juli 2024 14:38]

[Tijger]

Persoonlijk bemerk ik weinig verschil tussen Chrome and IE 11 op hetzelfde system.

[Boost9898]

Ik weet niet of het echt aan Windows 10 licht of dat ik het me verbeeld. Maar ik heb het idee dat GTA V veel beter draait. (Terwijl in de settings nog DX11 selected is, hopelijk komt DX12 ook nog.)

[FeareX]

Toevallig heb ik gisteren GTA V even gespeeld onder Windows 10, en ik had dezelfde indruk. Mijn GPU is een AMD HD6850 met 1GB VRAM, dit zorgde onder Windows 8.1 voor wat kleine haperingen hier en daar, in Windows 10 lijken die vrijwel verdwenen te zijn.

[Boost9898]

Ook is het gebruik van de GPU met GTA V gezakt maat de prestaties niet. Soms had ik als ik naar de bergen/offroad ging dat er soms wat frames verloren gingen maar dat is ook niet meer. Hopelijk komen er uitgebreide benchmarks van Tweakers. GTA V Win 8.1 VS Win 10 en dan het liefst met meerdere GPU's. Zelf heb ik een 980 Ti, jij?

[Verwijderd]

En dit komt niet omdat je nu een vesse instalatie van window heb ? en er dus minder programma's maar mischien ook virussen op de achtergrond mee draaien ?

verder zou het idd kunnen dat windows 10 mischien beter met multicore CPU's kan omgaan en dat daarom je wat winst ziet, maar zolang directx12 niet uit is betwijfel ik het.

Maar over een paar dagen ga ik mijn game desktop ook naar windows 10 overzetten: clean install. dan kan ik het eens testen

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:38]

[PauseBreak]

Windows 10 installeert automatisch alle programma's die je geïnstalleerd had staan in Windows 7 of 8.1, dus dat lijkt me niet het geval. Ik heb ook wel de ervaring dat meerdere games onder 10 beter en vooral vloeiender draaien dan onder 8.1 en 7 het geval was en ik heb gewoon een upgrade uit laten voeren.

[Game_overrr]

Ik had een wifi adapter van TP-link met een Realtek chip maar met Windows 10 heb ik totaal geen lag meer en een ping van 30ms ipv 25-999ms schommelingen. Ook met games merk ik een verschil en zeker met de laadtijden van GTA V

[Boost9898]

Ik heb inderdaad wel een clean install gedaan, voorheen draaide ik altijd op Windows Defender + MBAM. Wel heb ik GTA nu op m'n SSD draaien omdat 90GB toch voldoende is om over te houden.

[Indifstublatia]

Ik ben benieuwd.
Ik heb een watergekoelde i5 2400 3.1ghz, 8gb ram, boot SSD, verschillende SSHD's en een paar conventionele schijven en een Gigabyte HD7950 3GB OC (windforce-3).
Bij GTA Online (singleplayer verbazingwekkend genoeg niet) heb ik heel vaak dat complete gebouwen, wegen etc verdwijnen. Hopelijk lost DX12 het op.

Upgraden vind ik nog niet nodig. Alle spellen die ik speel, werken perfect op mijn systeempje (in een VEEL te grote kast ).

[downcom]

zelfde ervaring, GTA speelde op Windows 8.1 soms met behoorlijke framdrops. Daardoor heb ik zelfs op mn GTX-680 de settings allemaal naar normal gezet en zelfs toen bleef het niet optimaal.

Nu op windows 10 en natuurlijk de standaard instellingen via Nvidia Experience geen enkel probleem en -tig meer detail mogelijk zonder enige framedrop!

Het kan misschien met een frisse installatie te maken hebben maar toch het is opmerkelijk dat het nu veel beter speelt.

Ik ben echt enorm tevreden over windows 10 en de keuze die je als eind gebruiker hebt, wil je toch het metro menu, dan doe je dat, wil je start met een klein of groot metro menu? dan kies je daarvoor. En ik denk dat dit Windows 10 enorm sterk maakt.

Ik heb wel nog een opmerking, mijn Surface Pro 2 (en die van mn vriendin) gaan door de powerknop nauwelijks tot niet in standby / slaapmodus waardoor het scherm na 5 minuten even oplicht. Hebben meer mensen dit probleem?

[micla]

Hmm, ik ervaar juist het tegenover gestelde..GTA5 liep eindelijk 100% smooth op Win7 met de nieuwe catalyst driver ( heeft lang geduurd voordat CF goed werkte ), maar met Win10 ( fresh install ) heb ik eigenlijk in elke game, en vooral GTA nu last van microstutter. Zou Win10 problemen hebben met Crossfire?

[downcom]

Geen idee maar ik heb wel de drives voor windows 10 moeten installeren via Nvidia Experience. Daarmee worden oko direct de instellingen juist neergezet.

Al moet ik toegeven ik heb gister mn eerste happeringen gehad enorm veel mensen samen met veel politie, het blijft een ramp

Wat voor mij denk ik de bottleneck is, is de 2gb (videokaart) geheugen en de processor (i5). Binnenkort maar een upgraden (al ben vrees ik dan weer voor mn windows licentie...)

Edit: geheugen

[Reactie gewijzigd door downcom op 22 juli 2024 14:38]

[teunw]

Ik had gisteren hetzelfde met CS:GO, de controls voelden veel "anders" op de goede manier.
Ook leek de FOV aangepast.
Iets was anders dan normaal, kan alleen niet bedenken wat.
Denk dat het aan DX12 te danken is.

Had toch een paar mooie headshots gemaakt.

[Reactie gewijzigd door teunw op 22 juli 2024 14:38]

[Scraxxy]

Zou het aan raw input kunnen liggen? Mogelijk moet er een nieuwe fix komen?

Voor mij voelen shooters ook anders.

[teunw]

Ik heb zelf altijd Raw Input aan en accerlation uit, maar voor mij voelde de FOV heel raar aan.
Alsof deze wijder was dan normaal

[vSchooten]

dx 12 heeft hier weinig mee te maken, de engine heeft hun eigen versie van dx volgens mij 10/11 en runt daarmee hun engine...

[Mijiru]

Win10 komt ook met een nieuwe versie van DX11; met betere multi-threading.

[Cota]

Zit nu op w10 64 en merk het verschil ook goed in game performance tov w7 64. Met rtss osd opgemerkt dat het VRAM gebruik in F1 2015 en GTA V een stuk lager is in w10. Was in w7 vaak 250-500 MB hoger.

[SPOXYWOXY]

Snap wat je bedoeld, gisteren ook een game (Wolftenstein The New Order) geprobeerd welke voor mijn gevoel veel soepeler aanvoelde

[galadril]

Ik heb hetzelfde met Witcher 3..

[Ashketchum22]

even aanvulling op de intro: Voor windows 8.1 is kernel versie gegaan van 6.3 naar 10.0

Edit: Ik hoor op de achtergrond veel mensen uit mijn directe kring met problemen met de GPU driver na de update zowel van AMD als Nvidia. Wout, hebben jullie daar ook last van gehad en of een weigerende Nvidia driver installer gehad? Ik hoor nog wat geluiden namelijk dat de drivers die door Nvidia nauw zijn bijgewerkt voor de Win 10 tech versies nu weigerd te installeren voor de retail versie.

[Reactie gewijzigd door Ashketchum22 op 22 juli 2024 14:38]

[NotLikeTheOther]

Dit is opgelost met 353.62

[Dj Neo Ziggy]

Dit kan in bevestigen, mijn GT 760 werd herkend als een ATI?
Na 353.62 werd ie goed herkend.

[Ashketchum22]

Top dan weet ik dat Nvida en AMD er iig bovenop hebben gezeten

[arjan1995]

De installatie van versie 353.62 crashte zojuist GeForce Experience en gaf vervolgens een C++ runtime error op Windows 8.1 (GT630M). Maar ik ga dit systeem toch maar een clean install geven, want ik denk dat het meer aan mijn Windows-installatie ligt dan aan de drivers zelf.

[NotLikeTheOther]

Je kan nog eventjes proberen het met DDU te fixen

[batjes]

Kernel versie van NT zegt al niets meer sinds Windows 7.

De oude kernel versienumering aangehouden zou het NT 9.0 zijn.

[mae-t.net]

Op basis waarvan stel je vast dat de kernelnummering nergens meer op slaat?

Windows 7 verhoudt zich mijnsinziens tot Vista zoals XP zich verhoudt tot 2000 (XP en 7 zijn geoptimaliseerde long time support versies op basis van hun verwante 5.0 respectievelijk 6.0 versie) en dat scheelde ook alleen maar een minor version. Zie voor de verwantschap tussen Vista en 7 bijvoorbeeld ook nieuws: Microsoft: Windows 7 wordt compatibel met Vista kortom daar is een minor versionverschil zonder meer correct.

Je zou hooguit kunnen betogen dat het vanaf 8 niet meer klopte omdat er in 8 ook onder de kap kennelijk nog wat dingen omgegooid zijn ten opzichte van 7, al waren dat ook al geen grote dingen en is dat tussen Vista en 7 ook gebeurd. Ik zou zonder detailkennis van de gesloten broncode niet durven zeggen dat dat verschil (onder andere wat snelheidswinst, jammer dat 7 niet mee is genomen in de benchmark) een major version zou rechtvaardigen.

Kortom, als het puur om de kernel gaat, denk ik dat Windows 10 eigenlijk NT7 is, en als je de user interface meetelt (want dat was bij 8 wel een grote verandering of eigenlijk aanvulling) dan eventueel NT8, maar dat Windows 10 eigenlijk Windows 7 of 8 is, kan marketingtechnisch natuurlijk niet. De keuze van MS om de major version op deze manier weer duidelijk en ondubbelzinnig te maken lijkt me logisch.

[Reactie gewijzigd door mae-t.net op 22 juli 2024 14:38]

[batjes]

Ik dacht dat die blogpost onderdeel was van Engineering Windows 7 op MSDN, helaas. Even verder gezocht, kon het zo niet terug vinden.

Maar kwam erop neer dat MS geen zin had het gezeik van de OEMs weer over zich heen te krijgen en heeft toen in Windows 7 een complete driver compatibiliteitslaag voor Vista drivers gemaakt en de kernel op 6.* laten hangen zodat ze niet weer tegen het probleem van Vista aanliepen. De Driver module is in Windows 7 weer helemaal verbouwd.

Maar Windows 7 en 8 hebben beide genoeg wijzigingen in de kernels dat het geen minor releases zijn zoals de point releases wel aangeven.

http://blogs.msdn.com/b/e7/
http://blogs.msdn.com/b/b8/

[Loller1]

Windows 8 was, ook onder de motorkap zeker wel een NT 7.0 waard geweest, en dat dacht Microsoft ook want de eerste Windows 8 builds drogen NT 7.0 als versie.

[Ashketchum22]

zegt het wel batjes, want vanaf Windows 7 zijn het aanpassingen/verbeteringen geweest op de Kernel die in Windows Vista gebruikt is.

Het zijn geen volledig nieuwe kernels geweest.

Vista : 6.0
Win 7: 6.1
Win 8: 6.2
W8.1: 6.3

Win 10 had in de start van de TP kernel 6.4, later veranderd naar 10.0

[Armin]

En dat laatste is vooral gedaan omdat anders applicatie ontwikkelaars de kernel-versie zouden gaan misbruiken voor de zoveelste brakke versie test

Op applicatie niveau is dat "opgelost" door effectief tegen alles en iedereen te liegen over de versie zodat er altijd uit komt dat het "compatible" is. Op kernel niveau nu dus ook door het ook 10.0 te noemen. En de verwachting is dat dat nummer nu ook bevroren zal blijven. Al zullen er vast wel weer halve gare ontwikkelaars zijn die nu de build-nummers gaan gebruiken

[D0gtag]

Gisteren ook inderdaad problemen gehad, moest ze handmatig 'updaten' en restarten toen deed me scherm het(op normale res.), ik ga straks ook kijken of het inderdaad ook gamen mogelijk maakt (gtx970) Me laptop installatie verliep zonder problemen en alles was meteen overgezet (niet het geval bij me PC die ik na me laptop installeerde) in me laptop zit een nvidia quadro maar die draaide zonder enige problemen.
Vooralsnog erg tevreden over windows 10, het kan nog wel lastig zijn voor digibeten die hun pc moeten upgraden. Het is wel weer even zoeken maar gelukkig werken de shortcuts nog gewoon. : windows + x

[Ashketchum22]

ik begrijp dat vrienden van mij met een GTX 980 nogsteeds gedoe in games hebben (lage FPS etc) met de nieuwste drivers dus alle bugs zijn er voorlopig nog niet uit

[ColonelPhantom]

Jammer dat er niet gebenchmarkt is met W7, W8.1 en W10

[Nny]

Ja dat vind ik ook jammer, denk dat veel mensen juist van Win7 de overstap willen maken.

[Douweegbertje]

Inderdaad, ik heb absoluut geen officiële percentages maar ik denk dat er meer mensen van Windows 7 overgaan op Windows 10 dan vanuit Windows 8, 8.1.
Volgens deze website is de marketshare van Windows 7 een heel stuk groter dan wat dan ook: http://www.netmarketshare...aspx?qprid=10&qpcustomd=0

[pjdijkema]

Ik zou eerder overstappen van 8.1 naar 10 dan van 7 naar 10. Ik vind windows 8.1 behoorlijk gebruikersonvriendelijk. Wisselen tussen oude en nieuwe omgeving en toen ik de laptop voor het eerst wilde uitzetten moest ik via Google uitzoeken hoe dit moest. En ja ik ben best handig met windows. windows 10 voldoet voorlopig prima aan de positieve verwachtingen .

[Reactie gewijzigd door pjdijkema op 22 juli 2024 14:38]

[Bliksem B]

Echter prestatie technisch was windows 8 al een stuk beter dan Windows 7. Bij de mantle tests van hardware.info zag je dat heel goed terug. Battlefield 4 presteert onder Win8 tot wel 60% beter. (al is bf wel een uitzondering)

Dus van Windows 7 raad ik het daarom aan om juist over te stappen. De guigui is met Windows 10 voor minder windows 7 gebruikers een hekel punt is.

[Reactie gewijzigd door Bliksem B op 22 juli 2024 14:38]

[drdelta]

Het kan aan mijn ogen liggen hoor, maar ik leest toch echt dat het verschil -0.1% tot +7.2% meer(/minder) FPS wanneer Windows 7 en Windows 8 (beiden met Mantle) vergeleken worden.

60% kan ik niet terug vinden in dat artikel.

[Reactie gewijzigd door drdelta op 22 juli 2024 14:38]

[Bliksem B]

Kijk eens goed bij de core i7 4770 (260X). Neem bijvoorbeeld de medium settings ongeveer 50 FPS (wel of geen mantle) met Windows 7 en 80 fps bij windows 8. Bij de ultra settings ongeveer 20 met windows 7 en 30 met Windows 8.

Nu hangt er vanaf hoe je het berekent, maar tenopzichte van 20fps haal je 50% meer fps wanneer je 30 fps haalt: 100/20*30 = 150 ofwel 50% . Ten opzichte van 30 fps zijn 20 fps 33% langzamer.

[Tunestwo]

Dan zoek je de benchmarks op van Windows 7 tegen over Windows 8. Maar volgens mij was win 8 over het algemeen al sneller.

[Durandal]

Als ik toch moet gaan zoeken kan ik beter gelijk google in duiken op zoek naar een review site die ze wel alle drie heeft en Tweakers links laten liggen. Dat scheelt weer moeizaam vergelijken tussen 2 artikelen.

Jammer inderdaad, want Win 7 en ik blijf liever 'thuis'.

[Verwijderd]

Niet willen maar 'moeten' om de nieuwste updates en programma's te kunnen gebruiken zul geen andere keuze hebben.

[KnightSimon]

Ja, ik ben benieuwd wat Windows 10 doet op een oudere laptop thuis, waar nu nog Windows 7 op draait. Enig idee hoe dan de performance zal zijn?

[Illegal_Alien]

Ik heb zelf ene Dell Studio 15 uit het jaar 2009, deze had Windows 7 Home Premium, nu geupgrade naar Windows 10 en dat werkt een stuk soepeler. (Had onder Windows 7 al een SSD erin geplaatst.)

Specificaties weet ik zo even niet uit mijn hoofd.

Ik hoop wel dat Kaspersky snel met een update komt, op dit moment werkt KIS2015 op halve kracht. (En geen realtime controle.)

Als ik vandaag weer thuis ben ga ik windows 10 ook proberen op me Acer One Netbookje daar staat nu Windows 7 Starter op. En is een Intel Atom met 1 GB geheugen.

[Reactie gewijzigd door Illegal_Alien op 22 juli 2024 14:38]

[horizon1978]

Er hadden ook mindere systemen getest mogen worden ipv alleen I7's.

[Martinspire]

Welke drivers zijn gebruikt voor deze test? En waarom niet nog een Desktop systeem met AMD CPU en GPU?
Verder vind ik het opvallend dat de scores van Edge afwijken van de benchmarks van Microsoft. Enig idee waar dat aan ligt?

[jaquesparblue]

Vind het ook apart dat er nu ineens wel met Mantle getest wordt maar in alle laatste AMD reviews werd het weggewuifd omdat het heden ten dag niet relevant zou zijn.

Waarom wordt er geen low-end desktops getest? Win10 zou juist daar snelheidswinsten behalen tegenover 8(.1). Nu lijkt het alsof het amper de moeite is om te upgraden terwijl er enkel met een configuratie is getest die vrijwel niemand thuis heeft staan.

[The Fox NL]

Ik denk dat Tweakers een systeem met AMD gpu had liggen en dat daarom de Mantle resultaten erbij zitten, ik bedoel, je hebt ze nu toch?

Verder is het inderdaad jammer dat er geen low-end desktop is getest, maar gelukkig is er een laptop en een Surface getest, dus je ziet inderdaad dat op low-end systemen de (grafische) prestaties stijgen.

[Teijgetje]

Was inderdaad ook mijn eerste gedachte...alleen i7 systemen ? Of die sneller worden??
Terwijl driekwart van de wereld met i3`s op W7 zit omdat dat snel genoeg is/was?

Lijkt me een beetje gemiste kans zo.
Met benchmarks op low-end en medium(i5) systemen en met W7 erbij, daarvanaf krijg je immers W10 ook gratis, krijg je imo een eerlijker beeld wat voor verbetering W10 is tegenover de oude OS-en.

[Reactie gewijzigd door Teijgetje op 22 juli 2024 14:38]

[enchion]

En ook alleen synthetische benchmarks.

Op de desktop wat recente spellen aangooien en kijken of er enig verschil is was boeiender geweest dan dit.
En ook verschil in laad tijden voor tweakers.net was leuker geweest om te lezen. (niks anders is belangrijker nl)

DX12 is voor grafische toestanden en dan alleen met Intel hardware testen en niet met AMD of nVidia.

Beetje nonsense review imho, ik weet nu niets meer dan ik al wist.
(doe het goed of doe het niet)

[Reactie gewijzigd door enchion op 22 juli 2024 14:38]

[Madrox]

Ehmm, er zijn nog niet zoveel DX12 spellen. Weinig zinvol om DX11 spellen te gaan testen, wat je meet is het verschil tussen 8.1 en 10, behalve dan dx12 vs dx11; want dat laatste kan niet.

[enchion]

Ik had het niet erg gevonden om te lezen dat die theorie nu bewezen is in de praktijk test.

Daar gaat reviewen/benchmarken nl om.

Zoiets als deze dus. (zal ook niet perfect zijn maar is informatiever dan tweakers.)
http://www.guru3d.com/art...performance-review,1.html

[Reactie gewijzigd door enchion op 22 juli 2024 14:38]

[Madrox]

Gaat ook wel gebeuren, GTA V bijv. komt straks met een DX12 patch. Dat gaat nog even duren, maar zeker geen jaar. Wellicht volgen er meer titels, het word afwachten.

Je zal dus nog even geduld moeten hebben, maar ik snap je terughoudendheid niet goed; alle signalen staan op groen. Het is allang aangetoond dat DX11 inefficient is, met Mantle. Over theorie kan je dus niet spreken, het is al een feit. Het is wachten op het uitrollen van het "lab" naar de consumentenmarkt. Nu met DX12 zal iedereen dat straks ervaren. Zodra de eerste spellen daar zijn en/of sommige huidige spellen opgewaardeerd zijn naar DX12.

[Reactie gewijzigd door Madrox op 22 juli 2024 14:38]

[Verwijderd]

In edge kun je ''about:flags'' alles aanvinken en nog eens testen. bij mij was kraken gelijk aan dat van chrome.

Ik weet niet of ze dat hebben ontdekt? en of alle updates geïnstalleerd?

Ik snap ook niet waarom het nu al uit is terwijl edge nog steeds niet mee kan in benchmarks

Maar is vele male beter dan ie11.

[ÜberWicked]

Jammer dat er alleen i7 processoren getest zijn.
Ben zelf erg benieuwd hoe W10 draait op tablets en netbooks met o.a. atom processoren in vergelijking met W8

[albino71]

Ik heb Win 10 pro op een Medion E1210 staan.

Ding gaat nu als de spreekwoordelijke brandweer. Niet normaal zo snappy.

Dus, petje diep af voor Microsoft!

[itcouldbeanyone]

dat is inderdaad een goede
heb alleen een van de eerste atoms liggen.
miss iemand anders die ff kan testen ?

[justme256]

Ik heb Windows 10 hier draaien op een oude Acer met een Intel Pentium Duo T4300. Het is een systeem dat vanaf Windows 7 geüpgrade is naar 8, toen naar 8.1 en nu naar 10. Het mafste is dat hij nu het beste draait sinds ik hem gekocht heb (en ja, er zat ook een clean install tussen ergens bij Windows 7 of Windows . Ik had bij de preview versies op mijn testsysteem al het idee dat alles wat soepeler liep, maar nu op oude hardware kan ik het alleen maar beamen.

[prutser001]

Werkt gewoon goed op een D525 of D2550 (SSD - 4/8GB), N270 zou ik moeten zoeken...
Bij gewoon gebruik net zo snappy als een i3/5/7 het zal om fracties van een seconde gaan als je iets wilt opstarten.

Wat ik ook wel mis is dat mijn gemiddelde Win10 installatie 15-18GB is waar ik wel benieuwd ben hoe groot het kan worden. Kijk ik nu naar 3 verschillende systemen hier met Win7 dan is de gemiddelde installatie 30GB.

[Tom]

Edge is een jonge browser die zaken als extensions mist. Dat zou zonder ingeschakelde zaken geen invloed mogen hebben op de rendersnelheid van de engine, maar een vergelijk met volwassen browsers die meer functionaliteit hebben zoals Firefox en Chrome is niet helemaal eerlijk.

[Illegal_Alien]

Ik ben juist blij dat er geen extensies bijzitten. In mijn ogen moet een browser gewoon een browser zijn en niet allemaal toeters en bellen eraan vast. (Extensies)

[JAVE]

Extensies zitten niet vast aan de browser. Het is juist een ideale manier van functionaliteit toevoegen: Als je het nodig hebt, dan voeg je de extensie toe, en anders doe je het niet.

De browser wordt er niet groter/trager van als je de extensies niet gebruikt.

Zonder extensies wordt het geen browser die ik ga gebruiken.

[geertdo]

Het is al toegezegd dat extensions er komen.

'working on it' is de status.

https://wpdev.uservoice.c...category/87962-extensions

https://windows.uservoice...nsions-in-spartan-project

[SN4K3]

Zo'n opvatting over extensies had ik eerst ook, maar sindsdien heb ik toch een kleine verzameling van extensies geïnstalleerd waar ik niet meer zonder kan.

- Addblock
- Youtube magic actions
- Auto HD voor Youtube
- Reddit Enhancement Suite
- Sinds Windows 10 een ander thema (extensie?)

Zodra Edge deze extensies ook ondersteund stap ik denk ik over vanaf Chrome, want Chrome word me te zot met het aantal processen op de achtergrond en nu met W10 heb ik mijn Gmail account in de mail app en een Google account is straks ook niet meer nodig dus op dat vlak mis ik ook niets. Een paar weken geleden had ik al Firefox weer eens geprobeerd, maar dat is het hem ook net niet voor mij.

[prutser001]

Mee eens veel extensies in Chrome zijn voor mij nu ook dagelijkse kost

Ik heb dan ook nog :

Tampermonkey
Readability
Lazarus
Disconnect
Tunnelbear

[CH4OS]

Tools voor developers zou wel leuk zijn voor webdevelopers natuurlijk.

[ColonelPhantom]

Waarmee moet je het dan vergelijken?

[Tom]

Ik vind het vergelijk prima en logisch dat ze het doen, maar het kan een vertekend beeld geven. Laat je alle features van Firefox en Chrome achterwege zodat alleen de renderengine overblijft met een minimale UI, dan zullen die ook sneller zijn dan de full-blown browsers.

[hiostu]

Ik denk eerlijk gezegd dat het best wel meevalt. Alleen extentions die ingrijpen op de HTML rendering en javascript engines hebben invloed. De andere functionaliteiten zullen dat maar beperkt hebben, ook de UI invloed zal maar beperkt zijn.

[teacup]

Om in te haken op de DX12 performance, bij de draw calls per frame grafieken valt het me op dat DX 12 bij de 6 Cores CPU met hyperthreading iets minder presteert als dat de 6 cores worden gebruikt zonder hyperthreading. Het is niet eens dat hyperthreading geen invloed heeft, het heeft zelfs een negatieve invloed. Mantle lijkt trouwens wel een positief effect te kunnen bereiken bij gebruik van hypertheading.

Dit zou de twijfelachtige invloed van hyperthreading op grafische perfiormance verder onderstrepen. Bij CAD en FEM systemen wordt HT vaak al compleet uitgezet. Dit laatste kan trouwens ook als een tekortkoming van de software worden beschouwd, dat ze HT niet kan uitnutten.

Om het diplomatiek te zeggen: DX 12 geeft weinig reden om af te wijken van de consensus om voor game systemen te volstaan met (niet HT) i5 processoren.

[CH4OS]

Daarnaast is er natuurlijk ook nog geen enkele applicatie wat DirectX 12 goed benut. Juist die nieuwe API's zouden het verschil moeten brengen. De bestaanden zijn gewoon die van DirectX 11, met wat updates, dus dan is het (imo) logisch, dat de performance gelijk is. Dan is het ook niet zo vreemd, dat hyperthreading in sommige gevallen inderdaad een negatieve invloed heeft op de performance, want dit is - bij mijn weten - altijd al zo geweest.

[Madrox]

Er is niks twijfelachtig aan de performance van HT.
http://techbuyersguru.com...benchmark-analysis?page=1
Zodra een spel meer dan twee cores benut, zie je dat een i3 dulacore cpu profijt heeft van HT. Bigtime performancewinst, het verschil tussen onspeelbaar en goed speelbaar vaak. Bij de i5 met vier cores zie je dat juist niet omdat je daar ervaart dat spellen niet meer dan 4 cores goed benutten.
Er is dus met een quadcore geen cpu core bottleneck en als er geen bottleneck is, kan je die ook niet oplossen; ook niet met HT. Dat zit dan eerder in weg.

Conclusie; HT werkt, maar dan wel wanneer het nodig is. Er is al een spel waar HT positief effect heeft op een vier-cores cpu met HT, dat gaan er steeds meer worden gezien de komst van achtcores consoles. Spellen van straks gaan steeds vaker meer cores bemutten en ja, dan gaat HT, ook voor de quadcores met HT steeds meer een rol spelen. Hoeveel winst erin zit, zie je nu al met de scores van een i3 dualcore.

[Verwijderd]

Om in te haken op de DX12 performance, bij de draw calls per frame grafieken valt het me op dat DX 12 bij de 6 Cores CPU met hyperthreading iets minder presteert als dat de 6 cores worden gebruikt zonder hyperthreading. Het is niet eens dat hyperthreading geen invloed heeft, het heeft zelfs een negatieve invloed. Mantle lijkt trouwens wel een positief effect te kunnen bereiken bij gebruik van hypertheading.

Er wordt hier natuurlijk wel ingezoomd op de draw calls. Mogelijk zitten er nog wat issues in de vroege DX12-drivers waardoor het nog niet zo lekker schaalt naar 12 threads.
Daarnaast, zelfs als DX12 an sich trager is met 12 threads, dan nog betekent dat niet per se dat de game trager is.
De game heeft namelijk ook die 12 threads ter beschikking. Als de game meer tijd wint dan dat DX12 verliest in de draw-calls, is het nog steeds beter om HT aan te houden.