Co je to fúzní pojistka?

Pokud je mi známo, s DCTL zatím nikdo nic neudělal, takže jste první! @ČERVEN & netrpělivě očekávám vaše poznatky!

Nejsem si jistý, kolik času budu mít na přispění, ale pokud se mi to podaří, pokusím se pomoci. Před časem jsem prozkoumal OpenCL a vývojářské deníky pro toto úsilí jsou na mém blogu:
http://www.bryanray.name/wordpress/opencl-fuses-index/

Nevím, jestli to pro vás bude vůbec užitečné, ale jakmile se do toho pustím, první věc, kterou pravděpodobně udělám, bude projít stejnou cestou učení.

SirEdric Fusionator Příspěvky: 2394 Založen: Út 05. srpna 2014 10:04
Odpovědi: 12
Skutečné jméno: Eric Westphal Kontakt:

Re: Vývoj pojistek GPU Fusion 16

Odeslat SirEdric » Čt 02. ledna 2020 3:31

Hmmmm. z výše uvedeného článku to zní docela zajímavě!
DCTL lze použít ve stromu uzlů stejně jako LUT. Ale na rozdíl od LUT nemají pevný klip. Pomocí nich udržujete 32bitové zpracování s pohyblivou řádovou čárkou.
Pokud by tedy nyní někdo našel způsob, jak automaticky přeložit všechny ty gigazilióny souborů „Free Film LUT“
(z nichž některé mám skutečně rád, ale používám je zřídka kvůli ořezové věci) do DCTL,
použití LUT by ve skutečnosti *přidalo* k vašemu pracovnímu postupu, spíše než jen kastrovalo vše v proudu.

Chad Fusionator Příspěvky: 1788 Založen: Pá 08. srpna 2014 1:11

Re: Vývoj pojistek GPU Fusion 16

Odeslat Chad » Čt 02. ledna 2020 4:01

CTL byly původně vyvinuty jako náhrada za LUT, protože se ukázalo, že většina LUT má velmi zjednodušenou povahu. Jako proč vyrábět LUT, která provedla zisk nebo gama operaci, když je to vše, co potřebujete? Většina LUT byla vytvořena pomocí jednoduchého vzorce, takže si jej můžete ponechat a předpokládat, že cokoli, co použije LUT, může na obrázek také aplikovat nějaký fragment shader.

Mějte na paměti, že některé nástroje ResolveFX také klipují. Není to tedy tak, že by se CTL (nebo DCTL) nestříhaly, ale že se MUSÍ stříhat. Věci jako gama stejně nejsou určeny pro použití mimo rozsah 0-1.

Aleksander Příspěvky: 8 Založen: St 01. ledna 2020 9:08

Re: Vývoj pojistek GPU Fusion 16

Odeslat Aleksander » Čt 02. ledna 2020 7:14

Myslím, že hodně z toho mluví o souborech Resolve DCTL, které, jak se zdá, většina lidí používá k úpravě barev. Předpokládám, že to dává smysl.

ČTĚTE VÍCE

Je Seat stejně dobrý jako Škoda?

Ve srovnání s pojistkami o nich opravdu moc nevím, i když věřím, že syntaxe jádra je podobná?

Správce stránek SecondMan Příspěvky: 5286 Založen: Čt 31. července 2014 5:31
Odpovědi: 36
pronájem: Vancouver, Kanada Kontakt:

Re: Vývoj pojistek GPU Fusion 16

Odeslat SecondMan » Čt 02. ledna 2020 7:42

@Shem Namo @SirEdric @Chad @ČERVEN — Sloučil jsem diskuzi DCTL z tématu koláčového menu zde.

Všimněte si také, že DCTL mi připadá trochu nesprávné pojmenování. Zdá se, že každý si okamžitě vytvoří spojení s CTL (nepřekvapivě) a i když jsem si jistý, že v DCTL můžete dělat to, co CTL, z toho, co jsem zjistil, to jde mnohem dál.

Takže spíše než pocit pokroku, díky tomuto a nedostatku dokumentace, existuje představa, že OpenCL a další zábavné věci byly zavrženy ve prospěch akcelerace GPU korekce barev. Skutečnost je ale pravděpodobně mnohem růžovější. Mimochodem, všiml si někdo Rays Fuse, která je dodávána s Fu16?

Je to OpenCL Fuse.

Funguje ve Fu16.

Aleksander Příspěvky: 8 Založen: St 01. ledna 2020 9:08

Re: Vývoj pojistek GPU Fusion 16

Odeslat Aleksander » Čt 02. ledna 2020 7:45

Myslím, že pro začátek by byl nejlepší opravdu jednoduchý příklad, který by obecně pokryl to, co si myslím, že se děje. Za prvé, úplný zdroj jednoduché „ziskové“ pojistky, pro referenci:

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (DCTLTest.fuse)
FuRegisterClass ( «DCTLTest» , CT_Tool , REGS_Category = «Test» ,
TestParams = [[
plovoucí zisk;
int data-data-srcCompOrder;
TestKernel = [[

__KERNEL__ void TestKernel(__CONSTANTREF__ TestParams *params, __TEXTURE2D__ data-data-src, __TEXTURE2D_WRITE__ dst)

DEFINE_KERNEL_ITERATORS_XY(x, y);
float4 col = _tex2DVecN(data-data-src, x, y, params->data-data-srcCompOrder);
col.x *= params->zisk;
col.y *= params->zisk;
col.z *= params->zisk;
_tex2DVec4Write(dst, x, y, col);
funkce Vytvořit ( )
InGain = self : AddInput ( «Gain» , «Gain» , LINKID_DataType = «Číslo» ,
INPID_InputControl = «SliderControl» ,
INP_MinScale = 0.0 ,
INP_MaxScale = 2.0 ,
INP_Default = 1.0 ,
InImage = self : AddInput ( «Obrázek» , «Obrázek» , LINKID_DataType = «Obrázek» ,
LINK_Main = 1,
INP_AccceptsGPUImages = true ,
OutImage = self : AddOutput ( «Output» , «Output» , LINKID_DataType = «Obrázek» ,
LINK_Main = 1,
funkce Proces ( req )
local data-data-src = InImage : GetValue ( req )
local dst = Obrázek < IMG_Like = data-data-src , IMG_DeferAlloc = true >
lokální uzel = DVIPComputeNode ( req , «TestKernel» , TestKernel , «TestParams» , TestParams )
local params = node : GetParamBlock ( TestParams )
parametry . zisk = InGain : GetValue ( req ) . Hodnota
parametry . data-data-srcCompOrder = data-data-src : IsMask ( ) a 1 nebo 15
uzel : SetParamBlock ( params )
uzel : AddInput ( «data-data-src», data-data-src)
uzel : AddOutput ( «dst», dst)
local ok = uzel : RunSession ( req )
pokud ne ok, tak
OutImage : Set ( req , dst )

ČTĚTE VÍCE

Je Palisade pomalá?

Nemám v úmyslu, aby to bylo obecné téma psaní pojistek, takže se budu zabývat pouze podrobnostmi o podpoře GPU pro fusion 16.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
TestParams = [[
plovoucí zisk;
int data-data-srcCompOrder;

To definuje (jako řetězec lua) parametry, které chceme předat našemu jádru, kromě obrázků, které se dělají jinak. Zdá se, že jde o poměrně přímočarou strukturu C, která podporuje (alespoň) typy int a float. To předáme některým funkcím později.

Poté definujeme naše skutečné jádro, kód GPU, který chceme na obrázku spustit. Opět je to jako Lua řetězec.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
TestKernel = [ [

__KERNEL__ void TestKernel ( __CONSTANTREF__ TestParams * params , __TEXTURE2D__ data-data-src , __TEXTURE2D_WRITE__ dst )

Výše uvedené specifikuje samotnou funkci jádra (s příznakem __KERNEL__), přičemž bere (předpokládám, že tedy __CONSTANTREF__) strukturu parametru (kterou jsme definovali výše), jeden vstupní obrázek a jeden výstupní obrázek (který se zdá být označen __TEXTURE2D__ a klíčová slova __TEXTURE2D_WRITE__).

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
DEFINE_KERNEL_ITERATORS_XY ( x , y ) ;

To je pro mě v současnosti jedna z méně jasných věcí. Viděl jsem 1D i 2D (jako zde) verze. Předpokládám, že definuje magické proměnné představující aktuální pixel/prvek zpracovávaný na GPU. Samozřejmě x,y použité níže nejsou specifikovány jinde, takže v tuto chvíli předpokládám, že je to vytvoří.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
float4 col = _tex2DVecN ( data-data-src , x , y , params -> data-data-srcCompOrder ) ;
col . x *= parametry -> zisk ;
col . y *= parametry -> zisk ;
col . z *= parametry -> zisk ;
_tex2DVec4Write (dst, x, y, col);

Tento blok ve skutečnosti pixel zpracovává. První řádek jej načte z data-data-src do vektoru float4, poté vynásobí x,y,z (což je r,g,b) parametrem gain, který jsme předali, a poté jej zapíše do dst na stejné pozici.

Hlavní zajímavostí je zde parametr data-data-srcCompOrder. Zdá se, že je to založeno na tom, zda je zdrojový obrázek maska nebo ne. Proč tomu musíme říkat, že je to nejasné (určitě to může říct?), a také proč to není potřeba pro DST? Nicméně vzorky to dělají, takže předpokládejme, že to potřebujeme.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)

To je vše pro jádro (DCTL) část kódu.

I když to není specifické pro DCTL pojistky, jen poznamenám, že v Create, když vytváříme náš obrazový vstup, musíme mu říci, že zde můžeme pracovat s obrazy GPU. Bez toho to všechno běží mnohem pomaleji.

ČTĚTE VÍCE

Jaká je teplota motoru Nissan TITAN?

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
InImage = self : AddInput ( «Obrázek» , «Obrázek» , LINKID_DataType = «Obrázek» ,
LINK_Main = 1,
INP_AccceptsGPUImages = true ,
Nyní v rámci Process musíme udělat řadu věcí pro nastavení a používání jádra DCTL, které jsme vytvořili:
Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
funkce Proces ( req )
local data-data-src = InImage : GetValue ( req )
local dst = Obrázek

Zdá se, že pokud používáme obrázek pro zápis z GPU, měli bychom zadat IMG_DeferAlloc. Zdá se, že to stále funguje, pokud ne, ale myslím, že je to další optimalizační věc.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
lokální uzel = DVIPComputeNode ( req , «TestKernel» , TestKernel , «TestParams» , TestParams )

Zde vytváříme náš objekt zpracování GPU (myslím, že „výpočetní uzel“). Všimněte si, že zde specifikujeme jména a skutečné řetězce (shora) jak jádra, tak parametrů. Tyto názvy se musí shodovat s názvy použitými v řetězci jádra výše.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
local params = node : GetParamBlock ( TestParams )
parametry . zisk = InGain : GetValue ( req ) . Hodnota
parametry . data-data-srcCompOrder = data-data-src : IsMask ( ) a 1 nebo 15
uzel : SetParamBlock ( params )

Tím se načte parametr. objekt .. z uzlu, nastaví do něj naše hodnoty a poté jej nastaví zpět do uzlu k použití (předpokládám).

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
uzel : AddInput ( «data-data-src», data-data-src)
uzel : AddOutput ( «dst», dst)

Dále přidáme vstupní a výstupní obrázky a uvedeme jak název, tak popisovač obrázku. Opět platí, že názvy musí odpovídat výše uvedeným.

Kód: [Vybrat vše] [Rozbalit/sbalit] [Stáhnout] (Untitled.lua)
local ok = uzel : RunSession ( req )
pokud ne ok, tak
OutImage : Set ( req , dst )

Nakonec spustíme naši «relaci», což myslím znamená zpracovat ji. Zkontrolujeme návratnost, abychom zjistili, zda selhala, a v případě potřeby upravíme náš výstup.

To je vše pro jednoduchý, funkční příklad. Je tam větší složitost (zejména kolem skutečné syntaxe v jádře), o které budu mluvit dále v budoucnu.

Naposledy upravil Aleksander ve středu 18. března 2020 6:56, upraveno celkem 1krát.
Midgardsormr Fusius z Borgu Příspěvky: 2672 Založen: St 26. listopadu 2014 8:04
Odpovědi: 46
pronájem: Los Angeles, CA, USA Skutečné jméno: Bryan Ray Poděkováno: 1 čas Kontakt:

Re: Vývoj pojistek GPU Fusion 16

Odeslat Midgardsormr » Čt 02. ledna 2020 8:30

ČTĚTE VÍCE

Jaký je výhled pro Toyota v roce 2024?

SecondMan napsal: ↑ Čt 02. ledna 2020 7:42 Mimochodem, všiml si někdo Rays Fuse, která se dodává s Fu16?

Tak teď, to je povzbuzující. Ve skutečnosti jsem to neotevřel a neporovnal kód. Je to téměř stejné jádro OpenCL; argumenty jsou různé a existuje několik funkcí, které se liší*. To jsou fantastické zprávy! A něco, co někdo z BMD opravdu měl upozornit už dávno.

Momentálně není čas se v tom hrabat, Aleksandere, ale těším se, až si to zítra přečtu!

* Letmý pohled ukazuje, že convert_float() je nyní pouze float() a existují matematické funkce, které byly zjednodušeny. Vidím, že _expf() bylo mimo jiné nahrazeno exp() . Nebude to tedy tak jednoduché, jako pouhá změna deklarace, ale doufejme, že dokážeme identifikovat dostatek změn, abychom byli schopni najít a nahradit na většině jader OpenCL.

Správce stránek SecondMan Příspěvky: 5286 Založen: Čt 31. července 2014 5:31
Odpovědi: 36
pronájem: Vancouver, Kanada Kontakt:

Re: Vývoj pojistek GPU Fusion 16

Odeslat SecondMan » Čt 02. ledna 2020 9:59

Aleksander napsal: ↑ Čt 02. ledna 2020 7:45 Takže myslím, že pro začátek by byl nejlepší opravdu jednoduchý příklad, který by obecně pokryl to, co si myslím, že se děje.

No svatej cr*p (pokud omluvíte ten výraz). Vítejte ve WSL a šťastný nový rok, @Aleksandere – to je docela fantastické první téma, které tam máte. Moc vám za to děkujeme a toto téma je nyní v záložkách!

Midgardsormr Fusius z Borgu Příspěvky: 2672 Založen: St 26. listopadu 2014 8:04
Odpovědi: 46
pronájem: Los Angeles, CA, USA Skutečné jméno: Bryan Ray Poděkováno: 1 čas Kontakt:

Re: Vývoj pojistek GPU Fusion 16

Odeslat Midgardsormr » Pá 03. ledna 2020 1:42

Aleksander napsal: ↑ Čt 02. ledna 2020 7:45 Zdá se, že pokud používáme obrázek pro zápis z GPU, měli bychom zadat IMG_DeferAlloc. Zdá se, že to stále funguje, pokud ne, ale myslím, že je to další optimalizační věc.

Kdybych měl hádat, řekl bych, že to brání Fusion v přenosu rastru z VRAM do systémové paměti. Při testování Fu9 před chvílí bylo spouštění všeho se zapnutým OpenCL obvykle pomalejší než jeho vypínání. Chad se domníval, že obraz byl přesouván do a z VRAM v každém uzlu, místo aby zůstal na GPU po celou dobu. Samotné zpracování mohlo být rychlejší, ale úspory byly promarněny zbytečnými I/O.

ČTĚTE VÍCE

Jaký Mercedes poskakuje nahoru a dolů?

Tento atribut spolu s INP_AcceptsGPUImages = true na vstupu je pravděpodobně tím, co tento problém překonává. Ale opět je to dohad.

PeterLoveday Fusioneer Příspěvky: 225 Založen: Ne 14. září 2014 6:09
Odpovědi: 9

Re: Vývoj pojistek GPU Fusion 16

Odeslat Peter Loveday » Pá 03. ledna 2020 5:29

Midgardsormr napsal: ↑ Pá 03 2020:1

Aleksander napsal: ↑ Čt 02. ledna 2020 7:45 Zdá se, že pokud používáme obrázek pro zápis z GPU, měli bychom zadat IMG_IMG_DeferAlloc. Zdá se, že to stále funguje, pokud ne, ale myslím, že je to další optimalizační věc.

Tento atribut spolu s INP_AcceptsGPUImages = true na vstupu je pravděpodobně tím, co tento problém překonává. Ale opět je to dohad.

Ano, v podstatě jste zde správně. Ve skutečnosti se dějí dvě (související) věci.

Za prvé, INP_AcceptsGPUImages (což je ekvivalentní starému INP_AcceptsCLImages — Fu9 používal podobný mechanismus, *nestahoval se* mezi každým uzlem naslepo) naznačuje, že nástroj je schopen pracovat s obrázky GPU předávanými do tohoto vstupu. Všimněte si, že to nutně neznamená, že *budou* vždy, ale bez toho se jakýkoli obrázek GPU, který přichází, nejprve stáhne do paměti CPU. To může být obrovský zásah do výkonu, zvláště pokud se nástroj poté musí také znovu nahrát.

Za druhé, při vytváření nového (cílového) obrazu IMG_DeferAlloc zabrání tomu, aby byla pro obraz alokována vyrovnávací paměť CPU, dokud není potřeba jej stáhnout nebo cokoli jiného. Bez toho bude paměť CPU přidělena, i když se k obrazu teprve následně připojí vyrovnávací paměť GPU. Není to úplně stejný výkon jako výše, ale určitě to může zabrat čas (na některých operačních systémech více než na jiných) a je to trochu plýtvání, pokud jde o zdroje (nevyužitá paměť CPU bude s tímto obrazem sedět, i když není potřeba).