Threadripper functioneert niet goed bij renderen

[Verwijderd]

Ik ben sinds kort in het bezit van een Threadripper en maak veel gebruik van 3D rendering. Mijn vorige processor was een Intel 4770K en na veel positieve verhalen de keuze gemaakt om over te stappen naar de Threadripper.

Ik heb hiervoor een nieuwe systeem in elkaar gezet en gebruik het moederbord van gigabyte x399 aorus. Tijdens de installatie van Windows 10 had ik al enige problemen, na het aanzetten van CSM in de bios was dit verholpen. Ik heb na de installatie alle drivers geïnstalleerd en ook is het systeem voorzien van de laatste windows updates.

Ik ben meteen aan de slag gegaan met een aantal Blender demo benchmarks om het geheel te testen. Hier kon ik niets vreemds ontdekken, echter had een zware benchmark wel wat moeite om de scene te bufferen.dit vergeleken met mijn Intel systeem die dit veel sneller deed. het verschil was echter 1 minuut en ik heb hier verder geen waarde aan gegeven.

Een maand later ben ik de Threadripper gaan gebruiken als render systeem, echter ging het hier helemaal mis. Na het inladen van een behoorlijk zware scene liep het systeem tijdens het pre render proces geheel vast. Na 2 uur begon de Threadripper te renderen, dit verliep echter wel soepel en snel.

Ik heb toen mijn oude systeem de zelfde scene laten renderen, hier zat echter geen vertraging in. Ik heb vervolgens het aantal threads in blender verlaagd van 32 naar 20. Hier was wel winst in te behalen, echter moest ik nog steeds een uur wachter voordat het systeem begon te renderen. Het Intel systeem doet dit in 3 min. Pas bij 4 threads verliep alles normaal. het renderen verliep echter heel traag op 4 threads.

Ik heb veel geprobeerd qua ram geheugen. Eerst alles eruit en per stuk geprobeerd of er verschil was te merken, echter was hier niets opvallends te zien qua performance. Ik heb zowel 8 als 16 gb ram strips gebruikt, ook hier geen verschil te merken.

Het probleem is aangemeld bij Blender als bug, echter kunnen de developers er niet heel veel mee. Hier is meer info over het probleem te vinden met bijbehorende filmpjes: https://developer.blender.org/T53068

Ik ben nu erg benieuwd wat voor volgende stap ik kan nemen. Doe ik er verstandig aan om een ander moederbord aan te schaffen, is het wellicht toch het ram geheugen, of moet ik het in een andere hoek zoeken. Ik baal er behoorlijk van dat ik zo lang al bezig ben om het systeem normaal te laten draaien. Ergens weet je dat een nieuwe CPU op een nieuw platform enige problemen kan veroorzaken. Aan de andere kant ben ik juist voor de Threadripper gegaan om zwaar werk te verrichten, vervolgens werkt het slecht en werkt mijn oudere Intel systeem gewoon veel beter.

Mocht er iemand zijn die een idee heeft waar ik nu naar moet kijken, ik hoor het graag. Mocht ik meer info moeten leveren, laat het weten en ik zal het posten.

[Squee]

Interessant dat ze het op een Ryzen niet zien en nog niet op een Threadripper geprobeerd hebben daar bij Blender. Het beste zou zijn om met een performance profiling tool aan de slag te gaan om te kijken in welk deel van de code hij zoveel langer bezig is. Ik vermoed dat het een inefficientie in de Blender software is die gewoonweg niet goed schaalt; maar op kleinere multicores nog wel (het kan vrij snel uit de hand lopen als je van bijv 4 naar 16 cores gaat).

Om even verder te speculeren (educated guess gebaseerd op ervaring); het zou goed kunnen zijn dat ze een bepaalde atomic operatie doen op een gedeeld object dat heel erg zwaar belast wordt vanuit meerdere threads. Omdat een Threadripper uit twee Zeppelin dies bestaat, heb je een heel erg grote overhead als je contentie hebt tussen twee of meer threads die op de twee verschillende dies gescheduled zijn; dat heeft te maken met de latency van de bijbehorende cacheline die dan continue heen en weer moet schuiven over het Infinity Fabric tussen de twee modules. Binnen een enkele Ryzen ga je niet van je chip af en is het veel sneller; ook het on-chip netwerk van een grote Intel is daar vrij rap in. Ik vraag me af of ze dit probleem niet ook zouden kunnen reproduceren op een dual-socket systeem want daarbij heb je het zelfde latency probleem. Een dual quadcore bijvoorbeeld, maar misschien zijn dat niet genoeg threads om deze zware belasting na te bootsen.

[edit]: Ik heb geen ervaring met performance profiling op Windows, maar misschien kan je eens naar CodeXL kijken.

[ Voor 5% gewijzigd door Squee op 23-10-2017 12:08 ]

[CryRaven]

Zou je een lijstje van je volledige systeem willen posten?
Hoe je dat doet lees je hier:
Handleiding Pricewatch

Zijn de temperaturen in orde?

[maratropa]

Andere engines zoals Cinebench en bijv de vray benchmark renderen wel gewoon normaal? Het is puur blender die niet lekker werkt?

En het lijkt dus de stap voor het renderen te zijn waar het mis gaat.. Op zich zou threadripper daar iets trager kunnen zijn door de lagere coresnelheid dan jouw i7, maar 2 uur is natuurlijk niet normaal. interessant dat bij 4 threads het weer ok is...

Heb je beide geheugen modi geprobeerd, "game mode" en "creator mode"?

@Squee ik heb de production benchmark (ik neem aan deze) even gestart op m'n dual xeon, dat gaat redelijk snel naar het renderen zelf toe.

[ Voor 19% gewijzigd door maratropa op 23-10-2017 12:22 ]

[Squee]

maratropa schreef op maandag 23 oktober 2017 @ 12:09:
@Squee ik heb de production benchmark (ik neem aan deze) even gestart op m'n dual xeon, dat gaat redelijk snel naar het renderen zelf toe.

Die dual Xeon E5-2699 die in je profiel staat? Hoeveel threads had je de benchmark op laten draaien?

[Hero of Time]

Kan je kijken van welke productieweek de CPU is? In Ryzen en stabiliteit issue bij zware loads wordt namelijk een probleem gemeld met de nieuwe CPU's van AMD. Dat zou na een bepaalde week opgelost moeten zijn. Nu wordt er in 't topic gemeld dat de Threadripper geen probleem zou geven, maar wellicht dat er toch iets mis is wat niet direct zichtbaar is.

[Verwijderd]

Hier zijn mij volledige pc specs:

GTX 970 MSI 4gb
Samsung SSD 840
Samsung SSD 850 EVO
HXLC9500 CORSAIR Cooling Hydro Series H100i v2
HTTA03 AMD Ryzen TR 1950X
GTEG30 GiBy X399 AORUS Gaming 7
TN7V2L03 be quiet! Pure Power 10 700W
Corsair Obsidian 750D
D432GB 2400-15 Fury Black

Ik heb een temperatuur test gedaan, hieruit blijkt dat het een minimale temp van 31 ºC heeft en een max van 54 ºC.

Het is echter niet zo dat op het moment van freezen/laadtijd er een hoge temperatuur is.

Wat betreft resultaten van andere programma's. Ik gebruik ook veel Agisoft, echter geen rare resultaten. Dit kan te maken hebben met een minder zware render opdracht, maar ik ga er even naar kijken.

Zowel de game als creator mode maakt geen verschil.

[maratropa]

Squee schreef op maandag 23 oktober 2017 @ 12:38:
[...]

Die dual Xeon E5-2699 die in je profiel staat? Hoeveel threads had je de benchmark op laten draaien?

(2x 2696 eigenlijk maar dat is dezelfde chip) vol belast op 64 threads (eigenlijk zijn er 72 threads maar paar cores staan uit ivm het willen hebben van 1 cpu group ipv meerdere) En cluster-on-die staat aan dus het OS ziet 4 NUMA nodes, elke node z'n eigen dual channel 32GB ram. (dus een beetje zoals threadripper met z'n verschillende dies) Als er latency issues zouden zijn in deze situatie dan zou ik denken dat ik ze had moeten zien..?

[Verwijderd]

Hero of Time schreef op maandag 23 oktober 2017 @ 12:42:
Kan je kijken van welke productieweek de CPU is? In Ryzen en stabiliteit issue bij zware loads wordt namelijk een probleem gemeld met de nieuwe CPU's van AMD. Dat zou na een bepaalde week opgelost moeten zijn. Nu wordt er in 't topic gemeld dat de Threadripper geen probleem zou geven, maar wellicht dat er toch iets mis is wat niet direct zichtbaar is.

Heeft dit ook betrekking op de Threadripper? Dit aangezien het niet staat aangemeld als probleem

[Squee]

Hero of Time schreef op maandag 23 oktober 2017 @ 12:42:
Kan je kijken van welke productieweek de CPU is? In Ryzen en stabiliteit issue bij zware loads wordt namelijk een probleem gemeld met de nieuwe CPU's van AMD. Dat zou na een bepaalde week opgelost moeten zijn. Nu wordt er in 't topic gemeld dat de Threadripper geen probleem zou geven, maar wellicht dat er toch iets mis is wat niet direct zichtbaar is.

Dat lijkt mij compleet ongerelateerd. Dat was een functionele bug die onder bepaalde load condities optrad, terwijl wat hier beschreven wordt toch duidelijk een performance issue is (er treden geen crashes/segfaults op en dergelijke).

[Squee]

maratropa schreef op maandag 23 oktober 2017 @ 12:45:
(2x 2696 eigenlijk maar dat is dezelfde chip) vol belast op 64 threads (eigenlijk zijn er 72 threads maar paar cores staan uit ivm het willen hebben van 1 cpu group ipv meerdere) En cluster-on-die staat aan dus het OS ziet 4 NUMA nodes, elke node z'n eigen dual channel 32GB ram. (dus een beetje zoals threadripper met z'n verschillende dies) Als er latency issues zouden zijn in deze situatie dan zou ik denken dat ik ze had moeten zien..?

Ok bedankt voor het proberen; dat sluit in ieder geval een erg voor de hand liggend probleem uit! Al hebben de Intel Xeons wel een andere cache topologie dan de AMD Threadripper, wat soms nog onverwachte effecten kan opleveren. Maar er is in ieder geval geen duidelijke scalability bottleneck daar te bespeuren.

Verwijderd schreef op maandag 23 oktober 2017 @ 12:42:
Zowel de game als creator mode maakt geen verschil.

In game mode heb je maar de helft van je threads beschikbaar, dus zou het in feite zich precies zo moeten gedragen als een 8-core Ryzen. Heb je toen ook het aantal threads in Blender teruggeschroeft naar 16? Als het in game mode op die manier ook voor komt en ze kunnen dat niet op een 8-core Ryzen reproduceren, dan is er toch wel echt iets vreemds aan de hand

Maar zoals altijd bij performance problemen: meten is weten. Als je een performance profile zou kunnen maken van Blender in die situatie, dan kunnen die jongens in je bugreport bij Blender daar ook een stuk meer mee.

[ Voor 0% gewijzigd door Squee op 23-10-2017 13:22 . Reden: typo ]

[Hero of Time]

Squee schreef op maandag 23 oktober 2017 @ 12:54:
[...]

Dat lijkt mij compleet ongerelateerd. Dat was een functionele bug die onder bepaalde load condities optrad, terwijl wat hier beschreven wordt toch duidelijk een performance issue is (er treden geen crashes/segfaults op en dergelijke).

Ik zou niet 'compleet ongerelateerd' willen zeggen. Wellicht is er wel een relatie en zit er een andere fout in de CPU of wordt deze op een andere manier geuit. Ik geef 't alleen aan dat er mogelijk een issue met de CPU is wat (nog) niet bekend is.

Verwijderd schreef op maandag 23 oktober 2017 @ 12:48:
[...]

Heeft dit ook betrekking op de Threadripper? Dit aangezien het niet staat aangemeld als probleem

Dat wat in het gelinkte topic wordt genoemd niet, maar er kan wel een ander probleem zijn. Iets om uit te zoeken zou ik zeggen. Ergens hoop je hierop, want dan heb je een verklaring en mogelijk fix. Anderzijds wil je het weer niet, want dat betekend dat je je CPU moet opsturen voor RMA.

[Verwijderd]

Squee schreef op maandag 23 oktober 2017 @ 13:12:

In game mode heb je maar de helft van je threads beschikbaar, dus zou het in feite zich precies zo moeten gedragen als een 8-core Ryzen. Heb je toen ook het aantal threads in Blender teruggeschroeft naar 16? Als het in game mode op die manier ook voor komt en ze kunnen dat niet op een 8-core Ryzen reproduceren, dan is er toch wel echt iets vreemds aan de hand

De scene laadtijd wordt nu gereduceerd naar 10 minuten. Ik maak dan gebruik van 16 threads in Blender. echter maakt het geen verschil of dit gebeurd onder de game of creator modus. Als ik 10 threads gebruik duurt het ongeveer 6/7 minuten. Vandaar dat bij 4 threads het op een normaal niveau is.

Je merkt dus een duidelijk verschil hoe minder threads, hoe sneller het pre-render proces duurt. Ik ga zeker een performance profile maken, maar ik was benieuwd of ik het moest zoeken bij mijn eigen setup, of dat het Blender gerelateerd is.

Dat wat in het gelinkte topic wordt genoemd niet, maar er kan wel een ander probleem zijn. Iets om uit te zoeken zou ik zeggen. Ergens hoop je hierop, want dan heb je een verklaring en mogelijk fix. Anderzijds wil je het weer niet, want dat betekend dat je je CPU moet opsturen voor RMA.

Is dit dan een kwestie van serienummer invoeren en kijken of je een match ergens op het web tegenkomt, dat dit type corrupt is? lijkt mij dat als er überhaupt een bugged threadripper is, dit via AMD bekend is.

[Astennu]

Hero of Time schreef op maandag 23 oktober 2017 @ 12:42:
Kan je kijken van welke productieweek de CPU is? In Ryzen en stabiliteit issue bij zware loads wordt namelijk een probleem gemeld met de nieuwe CPU's van AMD. Dat zou na een bepaalde week opgelost moeten zijn. Nu wordt er in 't topic gemeld dat de Threadripper geen probleem zou geven, maar wellicht dat er toch iets mis is wat niet direct zichtbaar is.

Dat zou het niet mogen zijn op threadripper cpu's. Zie ook een post van TechPowerup:

AMD Confirms Ryzen Marginality Performance Issue Under Linux, TR and EPYC Clear
by Raevenlord Tuesday, August 8th 2017 08:38 Discuss (45 Comments)
An issue on AMD's Ryzen performance under certain Linux workloads, which caused segmentation faults in very heavy, continuous workloads on the Ryzen silicon (parallel compilation workloads in particular) has been confirmed by AMD. Tests like Phoronix's Test Suite's stress run quickly bring the Ryzen processors to their knees with multiple segmentation faults. While this problem is easy to cause under very heavy workloads, the issue is virtually absent under normal Linux desktop workloads and benchmarking,

AMD also confirmed this issue is not present in EPYC or Threadripper processors, but are isolated to early Ryzen samples under Linux (AMD's testing under Windows has found no such behavior.) AMD's analysis has also found that these Ryzen segmentation faults aren't isolated to a particular motherboard vendor, but are problems with the processors themselves. AMD encourages Ryzen customers who believe to be affected by the problem to contact AMD Customer Care. Some of those who have contacted customer care about the segmentation faults have in turn been affected by thermal, power, or other problems, but AMD says they are committed to working with those encountering this performance marginality issue under Linux. AMD will also be stepping up their Linux testing/QA for future consumer products.

[Hero of Time]

Verwijderd schreef op maandag 23 oktober 2017 @ 14:04:
[...]

Is dit dan een kwestie van serienummer invoeren en kijken of je een match ergens op het web tegenkomt, dat dit type corrupt is? lijkt mij dat als er überhaupt een bugged threadripper is, dit via AMD bekend is.

Denk 't wel, want aan het serienummer zie je de productiedatum. Het probleem wat ik linkte is puur en alleen voor Ryzen. Threadripper heeft misschien een ander issue. Of Blender kan er niet goed mee overweg. Who knows.

Astennu schreef op maandag 23 oktober 2017 @ 14:11:
[...]

Dat zou het niet mogen zijn op threadripper cpu's. Zie ook een post van TechPowerup:

[...]

Dat zei ik ook, die specifieke problemen zijn alleen voor Ryzen, maar geef aan dat er mogelijk een ander issue is met de andere CPU's van dezelfde generatie.

[Verwijderd]

hier is btw een performance test, het laat zien dat het op het oog prima draait. http://www.userbenchmark.com/UserRun/5496362

Wat opvalt is dat onder de 16 GB ram geheugen er vrijwel niets mis gaat. Kom je boven de 16 GB zie je duidelijk performance problemen als ik alle 32 threads gebruik. Dit verklaard naar mijn idee waarom alle benchmarks met Blender er goed uitzien, dit aangezien dit relatief kleine scenes zijn. Toch heb ik met de Blender productie benchmark al behoorlijk verlies ( +/- 3 min)

[maratropa]

@Verwijderd dat is 3 min verlies op het renderen zelf of inc. pre-render scene/geometry setup?

Wat zie je in de taskmanager eigenlijk qua belasting tijdens pre-render setup? Ik zie hier vooral 1 core full load en dan soms even kort full allcore load. Beetje hetzelfde als ik bij bijv. V-ray zie, vooral veel singlethreaded belasting voordat hij echt gaat renderen.

Heb je verschillende power profiles geprobeerd? HT (of hoe het ook heet bij AMD) als eens uitgezet?

[CMD-Snake]

Astennu schreef op maandag 23 oktober 2017 @ 14:11:
Dat zou het niet mogen zijn op threadripper cpu's. Zie ook een post van TechPowerup:

Op het forum van Phoronix waren wel posters die claimden een Epyc CPU te hebben die ook een segfault gaf.

Enige wat TS zou kunnen testen als hij toegang heeft tot de hardware is om dezelfde render te doen op een Intel CPU met hoge core count (Broadwell-E of Skylake-X). Als het daar net zo slecht gaat kan je het wijten aan Blender, als het bij een Intel CPU beter gaat lijkt het toch ergens in deze Threadripper te zitten.

[Verwijderd]

maratropa schreef op maandag 23 oktober 2017 @ 18:11:
@Verwijderd dat is 3 min verlies op het renderen zelf of inc. pre-render scene/geometry setup?

Wat zie je in de taskmanager eigenlijk qua belasting tijdens pre-render setup? Ik zie hier vooral 1 core full load en dan soms even kort full allcore load. Beetje hetzelfde als ik bij bijv. V-ray zie, vooral veel singlethreaded belasting voordat hij echt gaat renderen.

Heb je verschillende power profiles geprobeerd? HT (of hoe het ook heet bij AMD) als eens uitgezet?

Het scheelt 3 min in het pre-render proces. Zeg maar waar alle assets etc wordt ingeladen voordat het echte render werk begint. Het renderen gaat dan ook prima, het is puur het opbouwen wat enorme vertraging heeft bij de full 32 threads. Al ga je kijken naar een animatie van 200 frames is 3 min al heel veel, laat staan alles wat dar boven zit.

De enige render referentie is mijn andere workstation met een 4770K. Deze heeft 8 threads en doet alles zonder moeite. Ik moet er bij zeggen dat de grote ( Ram geheugen) van de render veel uitmaakt. Naar mijn idee zijn er niet zo heel veel Blender gebruikers die maximaal vermogen uit Blender proberen te halen, dit zorgt er dan ook voor dat dit soort problemen verborgen blijven.hoor graag feedback als die er is.

Mijn vermoeden is dat dit een Blender issue is, maar aan vermoedens heb je zo weinig. Agisoft, een relatief zwaar programma doet het prima.

Om nog terug te komen op de belasting in de task manager, deze gaat tot ongeveer 90 % qua CPU verbruik, dus niet maximaal. Wel is de 16GB grens het punt waar de problemen beginnen, alles daar onder gaat prima.

[maratropa]

@Verwijderd maar als je de taskmanager even op per-core weergave zet, je ziet wel 1 core full load staan tijdens inladen assets? (afgewisseld met wat full allcore load)

Heb je beschikking over een andere 3d app, om daar een flinke scene met veel geometrie in te laden en te kijken wat er dan gebeurt, vooral boven de 16GB? (al is het alleen maar een hair/fur object met gaziljoen strands oid)

Mijn eerste gevoel zou ook zeggen Blender issue icm threadripper idd..

Maar kun je eens testen net onder de 16GB? Dat is namelijk wel een "toevallige" grens.. (net als je ram in de andere "die" gaat nodig hebben.

En ik zou dus wel wat dingen uittesten nog om het uit te sluiten. Al getest zonder hyperthreading?

[CMD-Snake]

Er zit maar 16GB RAM in totaal in je PC? Met 16c/32t kan dat ook een onderdeel van je probleem zijn. Te weinig geheugen per core kan je machine soms enorm traag maken. Ooit een keer een geintje meegemaakt een server met een Xeon met ook een hoge core count die maar 4GB geheugen had... Dat was geen pretje, het OS was niet vooruit te branden tot er weer genoeg geheugen in zat. OS reageerde traag en de database die geïnstalleerd was hing constant.

Ik zou zo'n workstation toch snel van 32GB voorzien. Misschien hangt de boel ook minder dan ineens.

[maratropa]

@CMD-Snake in zn specs lijstje noemt hij een 32gb kitje

[SG]

Squee schreef op maandag 23 oktober 2017 @ 12:07:
Interessant dat ze het op een Ryzen niet zien en nog niet op een Threadripper geprobeerd hebben daar bij Blender. Het beste zou zijn om met een performance profiling tool aan de slag te gaan om te kijken in welk deel van de code hij zoveel langer bezig is. Ik vermoed dat het een inefficientie in de Blender software is die gewoonweg niet goed schaalt; maar op kleinere multicores nog wel (het kan vrij snel uit de hand lopen als je van bijv 4 naar 16 cores gaat).

Om even verder te speculeren (educated guess gebaseerd op ervaring); het zou goed kunnen zijn dat ze een bepaalde atomic operatie doen op een gedeeld object dat heel erg zwaar belast wordt vanuit meerdere threads. Omdat een Threadripper uit twee Zeppelin dies bestaat, heb je een heel erg grote overhead als je contentie hebt tussen twee of meer threads die op de twee verschillende dies gescheduled zijn; dat heeft te maken met de latency van de bijbehorende cacheline die dan continue heen en weer moet schuiven over het Infinity Fabric tussen de twee modules. Binnen een enkele Ryzen ga je niet van je chip af en is het veel sneller; ook het on-chip netwerk van een grote Intel is daar vrij rap in. Ik vraag me af of ze dit probleem niet ook zouden kunnen reproduceren op een dual-socket systeem want daarbij heb je het zelfde latency probleem. Een dual quadcore bijvoorbeeld, maar misschien zijn dat niet genoeg threads om deze zware belasting na te bootsen.

[edit]: Ik heb geen ervaring met performance profiling op Windows, maar misschien kan je eens naar CodeXL kijken.

Ipv atomic lijkt mij dat ze critical section met gedeelde data mutex lock gebruiken. En met latency over infinite fabric en verre mem controlers de latency voor langere lock tijd zorgt waarbij mogelijk de kans op wachten van alle andere threads op die ene niet alleen groot is maar altijd er flink massaal gewacht wordt op die ene thread. Blender mogelijk de CPU nog niet herkent en niet numa aware initialiseerd is. Dus net geen deadlock.
Met meer thread het wachten aanzienlijk wordt
Zou ook handig zijn als andere Threadripper eigenaren deze bug kunnen reproduceren eventueel met 64GB en 128GB setup.
En W10 of W10pro
Ook zou blender onder linux nog kunnen testen. Gezien windows versie port is van die andere main target.

[Verwijderd]

CMD-Snake schreef op maandag 23 oktober 2017 @ 22:50:

Ik zou zo'n workstation toch snel van 32GB voorzien. Misschien hangt de boel ook minder dan ineens.

Ik heb het systeem ook getest met een 64 GB setup, echter geen verschil.

Ook zou blender onder linux nog kunnen testen. Gezien windows versie port is van die andere main target.

Deze feedback kwam ook van het Blender support forum. Echter blijkt het zeer lastig om Linux / Ubuntu draaiend te krijgen vanwege AMD-V dat is disabled. In de bios is dit ook niet te activeren. Ik overweeg nu het MSI board aan te schaffen, puur vanwege betere support

[raymondw]

Heb je een PB gestuurt, helaas even via die weg totdat ik een akkoord heb voor fora posting.

[Squee]

Ten eerste, laat ik nog even de data die ik uit je verhaal/experimenten heb begrepen proberen samen te vatten in een tabel, kom gerust nog met aanvullingen/verbeteringen;

Threads	Kleine scene	Grote scene
32	7 mins	120 mins
20	-	60 mins
16	-	10 mins**
10	-	6 a 7 mins
4	2 mins	4 mins

** Hierbij maakte creator/game mode weinig tot geen verschil
Een "kleine" scene heeft een dataset van 10~11GB en een "grote" scene > 16 GB.

Verwijderd schreef op dinsdag 24 oktober 2017 @ 08:12:
Ik heb het systeem ook getest met een 64 GB setup, echter geen verschil.

Dat sluit opzich wel wat @maratropa suggereerde uit, dat het wellicht zou liggen aan dat je boven 16 GB naar de memory controllers op de andere module moet, aangezien je dan 32GB per module had gehad. Mijn vermoeden is nog steeds dat het een locking/contentie probleem is, maar de vraag is waar het zit. Aangezien je aangaf dat het ook erg afhankelijk was van je dataset grootte zou het ook nog een issue kunnen zijn in de schaalbaarheid van Blender zijn eigen memory/object management of wellicht zelfs Windows z'n virtual memory management, dat zijn vaak platform specifieke implementaties, en misschien is dat nog niet op dit moment voor Threadripper geoptimaliseerd.

@maratropa: was jouw dual-Xeon test ook een Windows machine, of draaide dit op Linux? @Verwijderd: Je zou met een LiveCD of USB Live editie zonder installatie makkelijk een Linux distributie moeten kunnen starten zonder het op je systeem te hoeven installeren. AMD-V support zou dan als het goed is niets uit hoeven maken. Een paar vergelijkbare tests onder Linux zou wel wat meer uit kunnen sluiten.

Om nog een ander experiment voor te stellen; zou je eens met de process explorer een vergelijking kunnen maken van een 32-thread "kleine" en "grote" scene run (dus een snelle en een trage), en dan vooral tijdens deze traag wordende pre-rendering fase eens kunnen kijken naar de het view->System Information overzicht en dan de "CPU" en "Memory" tabs. Misschien even wat screenshots maken? Ik had al eens door je eerdere videos heengeskipt maar ik geloof niet dat dit daar tussen zat (alleen proces en thread overviews staat me zo bij).

[SDSNATCHER2]

Hmmm kwam bij toeval dit topic tegen, ik heb zelf een identieke workstation.
(Zelfde moederbord, zelfde processor, zelfde behuizing, zwaardere voeding, 32GB)
Heb hem deze week in gebruik genomen, dus zal in de loop van de week wat testjes gaan lopen met Maya Vray. Kijken of daar ook vreemde dingen gebeuren... Laat dit wel even weten.

Mocht je echter heel graag hetzelfde eens op een ander "identiek" systeem willen testen, dan kan je me eventueel die test-scene sturen en een videorecording maken van de stappen die je doorloopt. Dan wil ik het ook best eens voor jou op mijn systeem testen. En de resultaten weer aan je terugkoppelen.

[Verwijderd]

Dit probleem is inmiddels opgelost. Zie verklaring Blender: https://developer.blender...6eeadfa1a7349bdb2bca47e38

[Squee]

Verwijderd schreef op donderdag 23 november 2017 @ 13:29:
Dit probleem is inmiddels opgelost. Zie verklaring Blender: https://developer.blender...6eeadfa1a7349bdb2bca47e38

Ha, leuk dat je dat nog even meldt! Zat ik toch in de goeie richting qua locks/atomics problemen.