Inlägg

Inlägg som CamelCase har skrivit i forumet
Av CamelCase
Skrivet av dunis90:

Nämnvärt är att DOOM stöder "Shader Intrinsics Function" på AMD-korten.

Som en uppföljning på tidigare svar så kan jag nämna att nvidia är på gång med extensions:

OK, inte lika dramatiskt som shader intrinsics, men det viktiga är att utökningar standardiseras och att arbetet görs publikt. Som jag sagt tidigare - git rules

Av CamelCase
Skrivet av xcluzive:

När väntas PCI 4.0 komma? Samt grafikkort till det?

Det enda jag känner till med pcie 4-stöd är power9 processorn. Inget för hemma-PC:n dessvärre! Den sägs vara på ingång om ca 6 mån.

Vvad gäller kort så känner jag bara till mellanox IB-kort, men det är superdatorinterconnect, inte grafik.

Av CamelCase
Skrivet av Mephiston:

Finner mer utförliga tester genom att titta på andra håll än sweclockers då de har stirrat sig blida på sitt prestanda index med sina metoder. Simpla tester och knappast mångsidiga med många brister... Samtidigt kritiserar Emil sina egna kunder varje tillfälle han får kritik eller sweclockers ifrågasätts.

Jag tycker det framgår att testandet är på kuriosanivå och att metodiken haltar en smula.

Av CamelCase
Skrivet av Yoshman:

Vilket är specifikt tillåtet och uppmuntrat "by-design" av både HLSL and SPIR-V! Enda anledningen att JIT:ad Java-bytekod i vissa fall är snabbare än kompilerad C/C++ kod är att den förra kan göra en första översättning från bytekod till maskinkod, köra en stund och samla in statistik kring vilken riktigt villkorade hopp tar och sedan använda denna information för att generera om maskinkoden från bytekoden.

Det går absolut att funktionellt göra samma sak på Nvidias kort, dock inte alls säkert att det är en bra idé prestandamässigt. Men problemet med "instrincs" ligger inte där.

Det normala för DX och Vulkan är att kompilera alla shaders till ett mellanformat, en bytekod, som är generell för alla GPUer. Det som distribueras är då bytekoden, något som har flera fördelar.

  • räcker att göra en kompilatorimplementation, i OpenGL distribuerades källkoden för shaders och skillnader i parser och tolkning av syntax har varit ett stort problem för OpenGL då det resulterat i olika resultat med olika drivers

  • att distribuera ett mellanformat i stället för maskinkod betyder att man på varje specifikt system kan generera maskinkod som mycket väl kan innehålla instruktioner som enbart finns på den aktuella kretsen, det är HÄR man ska se till att eventuella användbara instruktioner på GCN kommer till användning

  • hela grundtanken med "instrincs" är att helt eller delvis skippa mellanlagret, det som distribueras är då kretsspecifika instruktioner som dels låser det till de kretsar som har instruktionerna och dels hindrar/försvårar möjligheten till re-JIT till en mer optimal maskinkod baserad på statistik från körningar på aktuellt system

Om det nu är så att "shader instrincs functions" behövs så tyder det på att bytekoden för HLSL/SPIR-V har brister som borde ses över.

Som det är nu ligger det ju maskinkodsinstruktioner för GCN. Att emulera detta på en annan GPU är som att köra t.ex. ARM-kod på x86. Visst går det (t.ex. qemu), men man får vara glad om prestanda är en tiondel av att direkt köra motsvarande med x86 kod (då underliggande CPU är x86).

SPIR-V är explicit utökningsbart. Se sektion 3.1.

Vad gäller brister i mellanformatet så tror jag att, iaf vissa, av AMDs utökningar är aktuella för Vulkan 2.0. Ledsen, ingen källa på det, bara ngt som jag noterade i förbifarten nånstans.

Till sist, SPIR är inte bytecode, det är word32code.

Av CamelCase
Skrivet av PalmiNio:

Finner också det märkligt!

Inget test jag har läst på nätet lyckas ett GTX 1060 prestera bättre än RX480 på vulkan i 1440p:

RX480 vinner alla:
http://scr3.golem.de/screenshots/1607/D3D12-Vulkan-Test/thumb620/Direct3D12-Vulkan-Test-04.png

RX480 vinner alla:
http://www.pcgamesn.com/amd/rx-480-vs-gtx-1060-vulkan

RX480 vinner:
http://www.hardocp.com/images/articles/1468921254mrv4f5CHZE_4_3.gif'

RX480 vinner:
http://www.techspot.com/articles-info/1209/bench/Doom_02.png

RX480 vinner:
http://cdn.mos.cms.futurecdn.net/28EvXnog4P5j2vntsKzCfU-650-80.png

RX480 Vinner:
http://i.imgur.com/dZsgapm.png

Man undrar hur SweC lyckas pricka in så att just deras test så faller helt plötsligt RX480 ner i 1440p och dör mot GTX1060?

Underclock vs Superclock?

Du försöker dra slutsatser från ett test med obefintlig reproducerbarhet och (antagligen) betydande varians? Allt för att stödja en konspiratitonsteori? Riktig jäkla ekokammarnivå!

Av CamelCase
Skrivet av dunis90:

Nämnvärt är att DOOM stöder "Shader Intrinsics Function" på AMD-korten.

Så vitt jag begriper är det inget som hindrar nvidia att implementera:

  • AMD_shader_ballot

  • AMD_shader_trinary_minmax

  • AMD_shader_explicit_vertex_parameter

Iofs kanske de inte kan matcha det mot en enskild opcode men det borde gå att syntetisera funktionaliteten. De kommer inte åt de där sista procenten av prestanda men det borde rulla.

Av CamelCase
Skrivet av criscros:

väntar fortfarande på den dagen då igpun kan användas med andra gpuer och att det faktiskt hjälper

Borde gå att dedikera iGPU:n till compute. Förutsatt att båda GPU:erna har DMAstöd (VK_QUEUE_TRANSFER_BIT)

Av CamelCase
Skrivet av ClintBeastwood:

Tänk om den dagen någonsin kommer där man kan välja vilka inställningar som ska gå på de olika korten. Vissa grafikinställningar lägger man på AMD-kortet och andra på Nvidia-kortet beroende på vilket kort som presterar bäst i just det. Drömma går ju.

Teoretiskt sett bör det fungera, iaf på Vulkan då det använder ICD:er för de olika grafikkorten. Antagligen ngt liknande upplägg för DX12.

Av CamelCase
Skrivet av Yoshman:

När jag satt och lekte en del med OpenCL så blev slutsatsen att om gör något som innehåller en relativt stor andel villkorad körning så går det fortare att köra det på CPU-delen (SSE/AVX) än en GPU som på pappret har lång mer FLOPS. Det även när problemet i grunden var väldigt dataparallellt.

Kollisionsdektektering innehåller absolut villkorad körning så det lär inte heller bli speciellt effektivt på (dagens) GPUer.

Vad var Ageias PPU för typ av processor till designen, någon som vet?

Villkorad kod är juh döden för SIMD!

Du lekte inte med fulhack som "aritmetiska booleans"?

Av CamelCase
Skrivet av Zotamedu:

Personligen hoppas jag då att AMDs satsning på DSP tar mer fart för då kan man dumpa massa roliga ljudberäkningar på den istället för att belasta CPUn. Fast det krävs nog att DirectX och Vulcan lägger in stöd för det för att vi ska få med oss både AMD, Nvidia och Intel på tåget.

Rent teoretiskt borde det fungera. GCC kan juh generera kod för tensilica DSP, så det är bevisligen inte ogörligt. Sen blir det väl fejkad köhantering i drivrutinen men det går att leva med när föredlarna med att DSP:n programmeras m.h.a SPIR väger över.

Så nu väntar vi på vilka som fixar det först: AMD / cadence eller Qualcomm (som har hexagon DSP på snapdragon).

Av CamelCase
Skrivet av ArcticFire:

Vi får väl hoppas att alla är lika positiva när Nvidia kommer med sina egna "Shader Intrinsic Functions" och det kommer spel som är helt optimerade för Nvidia.

Undrar vad som händer när Nvidia kommer med sina funktioner?

Jag har svårt att se utvecklare som nappar på det. Det skulle innebära att de försvårar porteringsarbetet till konsoler. Dessutom, såååå stora vinster tvivlar jag på att det är med intrinsics. Den stora vinsten är async i sig.

Av CamelCase
Skrivet av Oaktree:

Ser inget problem ifall Nvidia skulle lägga till denna funktion, sålänge spelet fungerar på alla kort, som jag skrev i tidigare inlägget.

Nvidia kan väll lägga till sina funktioner i DOOM, om dom nu så önskar.

Klart de inte kan. Det är så vitt jag vet iDs egendom. Allt de kan göra är att erbjuda utvecklarna tekniska lösningar som snabbar upp spelen. Sen är det upp till utvecklarna att använda dem. Eventuellt låta sig övertygas av en påse pengar!

Av CamelCase
Skrivet av Snubb1:

Om du läst den länkade artikeln om IBM 7nm så hade du inte behövt skriva den kommentaren.
http://globalfoundries.com/newsroom/press-releases/2015/07/01...
Globalfoundries ligger i framkant med 7nm och jag hade inte blivit förvånad om GF äger det mesta av tekniken genom köpet av IBM Microelectronics och Samsung kommer licensiera teknik från GF för 7nm.

IBM betalade för bli av med det. You do the math. IBM är snälla nog att låta GF titta på forskningen inom området.

Av CamelCase
Skrivet av PalmiNio:

Intel bidrar nog inte med någon lägre kostnad, finns redan gått om mindre kinesiska tillverkare för det.

Intel har i åratal vant sig att lyfta enormt höga marginaler på x86 och därför aktivt hållt sig borta från ARM där marginalerna är mycket lägre.

Men då x86 inte ökar så blir Intel mer "desperata" vilket dock kan det bli en fråga om att Intel "köper" sig in på ARM marknaden med sin stora skattekista.

Skickades från m.sweclockers.com

Det är tveksamt om de har de finansiella muskler som krävs för det. Bakom GloFo finns ATIC och jämfört med samsung är intel en dvärg!

Av CamelCase
Skrivet av THB:

Trevligt.
Borde kunna innebära lägre priser på ARM kretsar med iomed att fler fabrikar tillverkar dessa.

Perfekt, eftersom det är enorm efterfrågan på nuclun-SOC:ar!

Av CamelCase
Skrivet av lanbonden:

Min första tanke när jag läste detta var:
"jaha, då sitter vi med 14/16nm för grafikkort tills tidigast 2020 om inte TSMC eller Samsung levererar 10nm"

Båda är om man ska tro rykten på gång med 10 nm. Samsung tillverkar antagligen snapdragon 830 redan nu.

Av CamelCase
Skrivet av IceDread:

Snacka om en stor mänd misslyckande. Det tyder på att de lär misslyckas med 7nm också eftersom de misslyckats med allt annat enligt artikeln.

Det slutar antagligen som med 10nm, dvs GloFo licensierar Samsungs process.

Av CamelCase
Skrivet av Yoshman:

I fallet 1) gissar jag att man inte ser tillräckligt stort värde i att gå utanför det HLSL/SPIR-V ger. I fallet 2) däremot borde både AMD och Nvidia ha egenintresse i att ge så stora fördelar till sin teknik att de lägger signifikanta resurser här. Inte alls säker att konsolerna väger upp det faktum att Nvidia har långt mer ingenjörer som jobbar med programvara jämfört med de som jobbar med kretsdesign.

Många verkar gilla att spy galla på Gameworks. Tittar man lite objektivt på det så är faktiskt renderingskvalitén kontra kostnaden i saker som FXAA, HBAO+, Waveworks m.fl. faktiskt minst lika bra som andra försök, det oavsett om man kör det på GCN, Kepler eller Pascal. En sådan sak som AO (ambient occlusion) är dyrt, så självklart kostar HBAO+ en del att slå på. Det kostar däremot ungefär lika mycket på alla arkitekturer och idag är faktisk alla Gameworks funktioner byggd ovanpå standard DX med HLSL så det fungera på alla GPUer.

Går garanterat att pressa ut lite mer ur kretsarna om man skippar HLSL, det kommer inte vara någon gigantisk mängd men säg att det är tillräckligt för att precis hamna före konkurrentens GPU i ett par titlar. PR värdet är då stort, värdet för användarna är mer tvivelaktigt och vi kan då se fram emot ett Gameworks som kanske bara fungerar på Maxwell och Pascal (dessa har väldigt snarlika funktioner, Kepler skiljer sig rätt mycket).

Som jag förstått det lilla jobbet att stödja både DX11 och OpenGL själva anropen mot de olika APIerna. Detta är rätt lätt att abstrahera. Den dyra delen är att konvertera HLSL till motsvarande GLSL.

Jag har ingen aning om hur stabilt det är men gslang verkar kunna svälja HLSL o spotta ut SPIR.

Av CamelCase
Skrivet av Albinfiskare:

Frågan är hur mycket bättre de olika gcn korten blir och om man kommer märka det. Tar inget för givet men hade varit kul om mitt 390x blir mer framtidsäkert om ac implementeras i framtida spel.

Skickades från m.sweclockers.com

Det beror på vilken sorts spel som köps. Vill folk ha många dynamiska effekter på skärmen så lär spelen gå i den riktningen. Dock med en viss fördröjning då async antagligen har en viss tröskel för utvecklarna.

Av CamelCase
Skrivet av IceDread:

Tänkte på en sak, man talar om asyncront och sekventiellt i artikeln och där vissa asyncrona anropen körs samtidigt med andra anrop. Tycker det lite konstigt att syncront skulle utesluta samtida anrop som tycks reserveras för asyncrona anrop.

Synkront innebär juh att du gör anropet o väntar på att det blir klart. Medans du väntar kan du inte göra andra anrop. Det gör å andra sidan att det är lätt att ha "koll på läget", dvs det görs en sak i taget.