abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 14:00 | Nová verze

Bylo vydáno openSUSE Leap 15.2. Přehled novinek v nejnovější verzi této linuxové distribuce v do češtiny přeloženém oznámení o vydání a v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
dnes 12:44 | Nová verze

Apache Guacamole, řešení pro vzdálený přístup k počítačům pomocí protokolů VNC, RDP a SSH z webového prohlížeče, bylo vydáno ve verzi 1.2.0. Přehled novinek v oficiálním oznámení. Zdůraznit lze podporu SAML 2.0, Wake-on-LAN, nové rozhraní pro přepínání mezi sezeními nebo překlad webového rozhraní do češtiny.

Ladislav Hagara | Komentářů: 0
včera 22:55 | Komunita

Nadace Raspberry Pi oznámila, že OpenVX 1.3 API lze nově používat také na Raspberry Pi. OpenVX je standard pro akceleraci aplikací počítačového vidění. Vyzkoušet lze ukázkové příklady.

Ladislav Hagara | Komentářů: 0
včera 22:11 | Zajímavý článek

Možná jste taky někdy zápasili s tiskem formulářů nebo šablon, které pořád ne a ne vyjít ve správné velikosti. Článek Tisk v přesném měřítku (PDF, PPD, CUPS) popisuje příběh hledání jedné takové chyby v GNU/Linuxu.

xkucf03 | Komentářů: 5
včera 08:00 | Nová verze

Byla vydána nová verze 4.8 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl aktualizován na verzi 9.5.1. Thunderbird na verzi 68.9.0. Linux na verzi 5.6.0. Opravena byla řada bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
30.6. 23:11 | Zajímavý projekt

Na Kickstarteru byla spuštěna kampaň na podporu tabletu CutiePi postaveného na Raspberry Pi, konkrétně na Compute Module 3+ Lite. Předobjednat jej lze za 198 dolarů. Expedice je plánována na listopad.

Ladislav Hagara | Komentářů: 4
30.6. 22:11 | Zajímavý článek

Na serveru Techrights.org vyšel článek The GNU Project is Bleeding Into Microsoft, který upozorňuje na podezřele se množící případy projektů, které jsou přesměrované z webových stránek GNU na GitHub (proprietární software a služba provozovaná Microsoftem). Článek poukazuje i na to, že k řadě přesměrování došlo po tom, co byl Richard Stallman (zakladatel hnutí GNU a nadace FSF) „vyhnán“ z vedení FSF (resp. odstoupil po agresivní

… více »
xkucf03 | Komentářů: 59
30.6. 18:00 | Komunita

Projekt KDE přešel na GitLab. Vlastní instance již běží na invent.kde.org. Další info v příspěvku na blogu GitLabu. Před dvěma lety byl na GitLab přesunut vývoj GNOME.

Ladislav Hagara | Komentářů: 5
30.6. 17:33 | Nová verze

Vyšel webový prohlížeč Mozilla Firefox 78.0. Jedná se o vydání s prodlouženou podporou (ESR). Počínaje tímto vydáním jsou k dispozici také poznámky k vydání pro podniky, kde jsou shrnuty změny týkající se zabezpečení, kompatibility a chování zvláště právě v podnikovém prostředí. Jednou z takových změn je odstranění podpory TLS 1.0 a 1.1.

Fluttershy, yay! | Komentářů: 2
30.6. 13:22 | Zajímavý článek

Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 95 (pdf), HackSpace 32 (pdf) a Hello World 13 (pdf).

Ladislav Hagara | Komentářů: 2
Používáte některé open-source řešení [protokol] pro šifrovaný instant messaging?
 (23%)
 (30%)
 (5%)
 (11%)
 (18%)
 (6%)
 (12%)
 (26%)
Celkem 286 hlasů
 Komentářů: 32, poslední 28.6. 17:51
Rozcestník

BlitJit – JIT Image Compositing for C++

1.3.2009 01:52 | Výběrový blog | poslední úprava: 31.8.2009 14:21

Tento blog byl smazán autorem

       

Hodnocení: 100 %

        špatnédobré        

Anketa

Má podle vás smysl optimalizovat grafické knihovny pomocí JIT kompilace?
 (82 %)
 (18 %)
Celkem 28 hlasů

Obrázky

BlitJit – JIT Image Compositing for C++, obrázek 1 BlitJit – JIT Image Compositing for C++, obrázek 2

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

stativ avatar 1.3.2009 09:13 stativ | skóre: 54 | blog: SlaNé roury
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Kéž by to zmiňované Cairo začalo využívat…
Ať sežeru elfa i s chlupama!!! ljirkovsky.wordpress.com stativ.tk
1.3.2009 10:31 janosh | skóre: 8 | blog: janosh_blog | Třebíč
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
hodne dobrej zapisek. Nechces to pak vydat jako clanek, nebo serial clanku?
Linux is like teepee, no windows, no gates, apache inside!
2.3.2009 18:24 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Upřímně si na články netroufám. Moc neovládám gramatiku, a témata, které mě zajímají, většinou zajímají strašně malý okruh lidí. Blog mi celkem vyhovuje, i když uvažuju o přesunu na nějaký spíš programátorský portál.

Když se nad tím zamyslím, tak já vlastně o Linuxu vůbec nepíšu. Všechno co dělám běží i pod Windows a v současnosti na programování používám nejvíce VS2005.
4.3.2009 09:11 Ladicek | skóre: 28 | blog: variace | Havlíčkův brod
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Jen hezky zůstaň tady, JIT kompilace (tedy v tomhle případě spíš JIT generování kódu) je super zajímavé téma :-)
Ještě na tom nejsem tak špatně, abych četl Viewegha.
4.3.2009 10:02 podlesh | skóre: 38 | Freiburg im Breisgau
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Když se nad tím zamyslím, tak já vlastně o Linuxu vůbec nepíšu. Všechno co dělám běží i pod Windows a v současnosti na programování používám nejvíce VS2005.
Nevadí, důležité je že to neběží jen pod Windows.
1.3.2009 10:39 Miloslav Ponkrác | blog: miloslavponkrac
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++

Ještě by mohlo umět uložit kód funkce jako objektový soubor pro slinkování s C/C++ kompilátorem a bylo by to dokonalé. :-)

2.3.2009 18:15 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Vzhledem k jit překladu není potřeba;) Generátor jit kódu je ale i tak velice optimalizovaný.
microcz avatar 1.3.2009 11:23 microcz | skóre: 18 | blog: Michalův zápisník | Praha
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++

zajímavé, na takhle nízké úrovni jsem se vykreslovacím procesem (jakožto skalní příznivec SDL) nikdy nezabýval, rád jsem se něco přiučil, děkuji za výborný článek

2.3.2009 18:10 Deleted [8409] | skóre: 14 | blog: darkblog
Rozbalit Rozbalit vše Re: BlitJit – JIT Image Compositing for C++
Díky za pozitivní reakce i výsledek ankety ;)

Vývoj je jen v začátku, další výsledky bych chtěl prezentovat jako porovnání rychlosti oproti SDL, Cairo a GDI.

31.8.2009 15:10 backup
Rozbalit Rozbalit vše Záloha: BlitJit – JIT Image Compositing for C++

BlitJit je nízkoúrovňová knihovna pro práci s grafikou pro C++, která je založená na just-in-time kompilaci grafických funkcí. V minulých zápiscích jsem představoval knihovnu AsmJit, která se stala srdcem knihovny BlitJit.

Úvod

Od prvního vydání knihovny AsmJit už uběhl nějaký ten pátek, tato knihovna se stále zlepšuje a nabývá nových vlastností. Při práci na knihovně BlitJit jsem si uvědomil, že je zapotřebí i něco víc než jen strohý assembler a přidal jsem do knihovny AsmJit i další třídu „Compiler“. Tato třída umožňuje vytvářet funkce pro různé volací konvence (calling conventions) a podporuje dokonce 32 a 64 bitů. O třídě Compiler bych chtěl v budoucnu napsat samostatný zápisek, nyní chci ale ukázat jen možnosti knihovny BlitJit.

Díky knihovně AsmJit a zmíněné třídě Compiler je tedy možné knihovnu BlitJit použít pro architektury x86 a x64 v 32bitovém i 64bitovém módu. Zatím jsem zkoušel jen 32bitový Windows a 64bitový Linux (moje kombinace OS), ostatní až časem (pod 64bitovým Windows očekávám chyby).

Motivace

Při podrobném prozkoumání ostatních grafických knihoven zjistíme, že každá knihovna potřebuje nízkoúrovňové grafické funkce, které se starají o kompozici pixelů. Tyto funkce většinou bývají napsané v C nebo se používají optimalizace pro MMX, SSE, atd... Když se kdokoliv na tyto funkce podívá podrobně, zjistí, že mají hodně společného. Každá funkce většinou pracuje nad nějakým polem (nejčastěji zdroj a cíl, ale při operaci s konstantní barvou jen cíl). Snahou většiny programátorů v této oblasti je maximálně optimalizovat tyto nízkoúrovňové funkce, protože na nich většinou závisí celkový výkon grafické knihovny.

Problém ručně psaných optimalizací je ten, že každá optimalizace se dělá přesně pro daný pixel formát (předem specifikovaný formát, podle kterého jsou pixely uložené v paměti) a s přibývající podporou více formátů nebo jejich vzájemným mixováním přibývá i nutný počet funkcí pro jejich efektivní zpracování. Protože některé knihovny obsahují opravdu široké spektrum formátů, ve kterých jsou uloženy pixely, řeší se tento problém tak, že zpracování probíhá ve více fázích:

  • Fetch - načtení zdrojových a cílových pixelů a převedení do vnitřního formátu
  • Composite – provedení kompozitní operace (míchání zdrojového a cílového pixelu)
  • Store – uložení cílového pixelu z vnitřního formátu do cílového formátu

Pokud si to spočítáme, zjistíme, že kompozitní operace pro běžnou operaci může znamenat až 4 fáze (2xFetch, 1xComposite a 1xStore). Každá fáze navíc znamená degradaci výkonu (je to vlastně poměr mezi obecnou implementací a výkonem, čím obecnější implementace, tím menší výkon a naopak). V praxi se to řeší tak, že se píší specializované implementace pro konkrétní formáty a kompozitní operace. Pokud implementace neexistuje, použije se obecná (slow path).

Návrh knihovny

Poslední dobou se snažím navrhovat knihovny tak, aby je bylo možné bez sebemenších problémů používat i jinde - minimalizace závislostí, nepoužívat stl, výjimky a rtti. S knihovnou BlitJit to není jiné. Jediné, co je potřeba pro zkompilování je knihovna AsmJit, na které je celý proces just-in-time kompilace založený.

Knihovna obsahuje třídu pro definování formátu pixelů (PixelFormat) a kompozitní operace (Operation). Formát pixelů je v současnosti implementován jen ARGB32-Premultiplied, ale kompozitní operace už je možné používat všechny (zatím jsou implementované jen operace, které definovali Porter & Duff a něco navíc).

Další třídy, které se používají jsou Generator (jedná se o hlavní třídu, která generuje JIT kód, viz dále) a MemoryManager (třída pro uchovávání a cachování již vytvořeného JIT kódu). V budoucnu se API ale určitě změní, bude potřeba přidávat formáty, kompozitní operace a přidat podporu pro efektivní vykreslování textu a transformace.

Třída Generator umí vytvořit funkce následujících prototypů:

// Broken in new version
typedef void (BLITJIT_CALL *FillSpanFn)(
  void* dst, const UInt32 src, SysUInt len);

// Implemented
typedef void (BLITJIT_CALL *BlitSpanFn)(
  void* dst, const void* src, SysUInt len);

// Not Implemented
typedef void (BLITJIT_CALL *BlitSpanMaskFn)(
  void* dst, const void* src, const void* mask, SysUInt len);

// Implemented
typedef void (BLITJIT_CALL *BlitRectFn)(
  void* dst, const void* src,
  SysInt dstStride, SysInt srcStride,
  SysUInt width, SysUInt height);

// Not Implemented
typedef void (BLITJIT_CALL *BlitRectMaskFn)(
  void* dst, const void* src, const void* mask,
  SysInt dstStride, SysInt srcStride, SysInt maskStride,
  SysUInt width, SysUInt height);

Kde dst je vždycky cílový buffer, src je zdrojový buffer nebo jedna složka (v případě FillSpanFn), len/width je šířka a height výška (s výškou je potřeba zadat i dstStride a srcStride pro skoky na další / předchozí řádek). Funkce se dají vytvořit pomocí generátoru. Vstup pro generátor je třída Compiler (definovaná v knihovně AsmJit, zde je serializován asm kód) a požadované formáty a druh kompozitní operace.

Použití

Pokud chce někdo použít knihovnu BlitJit, musí vzít v úvahu, že se jedná o nízkoúrovňovou knihovnu. Je potřeba několik kroků k tomu, aby se vytvořil JIT kód požadovaných parametrů. Například, pokud chci vytvořit funkci, která pro zdrojový a cílový formát ARGB32 provede operaci CompositeOver, musím zavolat následující kód:

// Memory manager nám usnadní alokaci paměti
BlitJit::MemoryManager memmgr;

// Compiler bude obsahovat serializovaný kód
AsmJit::Compiler c;

// Generátor potřebuje Compiler, kam bude kód serializovat
BlitJit::Generator gen(&c);

// Vytvoření požadované funkce ARGB32 <- ARGB32 : CompositeOver
gen.fillSpan(
  BlitJit::Api::pixelFormats[BlitJit::PixelFormat::ARGB32],
  BlitJit::Api::pixelFormats[BlitJit::PixelFormat::ARGB32], 
  BlitJit::Api::operations[BlitJit::Operation::CompositeOver]);

// Cast ukazatele na funkci, podobné jako reinterpret_cast<>
BlitJit::FillSpanFn fn = AsmJit::function_cast<BlitJit::FillSpanFn>(memmgr.submit(c));

Nyní jsme vytvořili funkci, kterou můžeme začít ihned používat, a která by měla být optimalizovaná pro současný procesor (nyní jsou implementovány optimalizace jen pro SSE2). Každá takto vytvořená funkce většinou obsahuje 1 hlavní cyklus, ve kterém je zpracováváno více pixelů současně a 2 cykly malé, které se používají na zarovnání cílového bufferu a zpracování posledních pixelů, které se nevešly do hlavního cyklu.

Třída MemoryManager pomáhá s alokací paměti, ve které může být spuštěný kód a ukládá do ní vygenerované funkce. Do třídy Compiler je serializován výstup z generátoru, který je pomocí memmgr.submit() převedený na opravdový strojový kód. Funkce memmgr.submit() vrací ukazatel na vytvořenou funkci. Jedná se o poslední krok, dočasné instance třídy Compiler a Generator by měly následně zaniknout.

Jen pro představu, asm kód, který tato funkce vygeneruje pro 32bitový x86 procesor vypadá takto (jedná se o log, stdcall konvence):

; BlitJit::Generator::blitSpan() - ARGB32 <- ARGB32 : CompositeOver
L1:
push ebx
push ebp
push esi
L2:
mov ecx, [esp + 24]
mov edx, [esp + 16]
mov ebx, [esp + 20]
mov ebp, 0x4317D0
pxor xmm0, xmm0
movdqa xmm1, [ebp]
cmp ecx, 0x4
jl L7
xor esi, esi
sub esi, edx
and esi, 0xF
jz L5
shr esi, 0x2
sub ecx, esi
L4:
movd xmm2, [ebx]
movd xmm4, [edx]
punpcklbw xmm2, xmm0
punpcklbw xmm4, xmm0
pshuflw xmm6, xmm2, 0xFF
pxor xmm6, [ebp + 16]
pmullw xmm4, xmm6
paddusw xmm4, xmm1
movdqa xmm6, xmm4
psrlw xmm4, 0x8
paddusw xmm4, xmm6
psrlw xmm4, 0x8
paddusb xmm4, xmm2
packuswb xmm4, xmm4
movd [edx], xmm4
add ebx, 0x4
add edx, 0x4
dec esi
jnz L4
mov esi, edx
and esi, 0x3
jnz L7
L5:
sub ecx, 0x4
jc L7
.align 16
L6:
movdqu xmm2, [ebx]
pxor xmm3, xmm3
pcmpeqb xmm3, xmm2
pmovmskb esi, xmm3
and esi, 0x8888
cmp esi, 0x8888
jz L9
movdqa xmm4, [edx]
movdqa xmm3, xmm2
movdqa xmm5, xmm4
punpcklbw xmm2, xmm0
punpckhbw xmm3, xmm0
punpcklbw xmm4, xmm0
punpckhbw xmm5, xmm0
pshuflw xmm6, xmm2, 0xFF
pshuflw xmm7, xmm3, 0xFF
pshufhw xmm6, xmm6, 0xFF
pshufhw xmm7, xmm7, 0xFF
pxor xmm6, [ebp + 16]
pxor xmm7, [ebp + 16]
pmullw xmm4, xmm6
pmullw xmm5, xmm7
paddusw xmm4, xmm1
paddusw xmm5, xmm1
movdqa xmm6, xmm4
movdqa xmm7, xmm5
psrlw xmm4, 0x8
psrlw xmm5, 0x8
paddusw xmm4, xmm6
paddusw xmm5, xmm7
psrlw xmm4, 0x8
psrlw xmm5, 0x8
paddusb xmm4, xmm2
paddusb xmm5, xmm3
packuswb xmm4, xmm5
movdqa [edx], xmm4
L9:
add ebx, 0x10
add edx, 0x10
sub ecx, 0x4
jnc L6
add ecx, 0x4
jz L8
sub ecx, 0x2
jc L10
.align 8
L7:
movq xmm2, [ebx]
movq xmm4, [edx]
punpcklbw xmm2, xmm0
punpcklbw xmm4, xmm0
pshuflw xmm6, xmm2, 0xFF
pshufhw xmm6, xmm6, 0xFF
pxor xmm6, [ebp + 16]
pmullw xmm4, xmm6
paddusw xmm4, xmm1
movdqa xmm6, xmm4
psrlw xmm4, 0x8
paddusw xmm4, xmm6
psrlw xmm4, 0x8
paddusb xmm4, xmm2
packuswb xmm4, xmm4
movq [edx], xmm4
add ebx, 0x8
add edx, 0x8
sub ecx, 0x2
jnc L7
L10:
add ecx, 0x2
jz L8
movd xmm2, [ebx]
movd xmm4, [edx]
punpcklbw xmm2, xmm0
punpcklbw xmm4, xmm0
pshuflw xmm6, xmm2, 0xFF
pxor xmm6, [ebp + 16]
pmullw xmm4, xmm6
paddusw xmm4, xmm1
movdqa xmm6, xmm4
psrlw xmm4, 0x8
paddusw xmm4, xmm6
psrlw xmm4, 0x8
paddusb xmm4, xmm2
packuswb xmm4, xmm4
movd [edx], xmm4
add ebx, 0x4
add edx, 0x4
L8:
L3:
pop esi
pop ebp
pop ebx
ret 0xC

64bitový kód vypadá podobně, akorát se používají 64bitové registry a zpracování parametrů funkce a návrat vypadá trochu jinak.

Testování

Pro testování a odladění knihovny jsem používal pár png ikonek, které jsou z projeku Crystal Project Icons. Tyto ikonky jsem zkoušel míchat a testoval jsem i rychlost vykreslení 10.000 ikon (rozměry 128x128).

Screenshoty z testovací aplikace jsou na konci blogu

Rychlost

Rychlost knihovny je podle mě výborná. Momentálně jsem se soustředil na optimalizace pro SSE2, které opravdu postrádám v mnoha známých knihovnách (včetně pixman/cairo, X server, gdk-pixbuf, agg, evas, imlib2, v současném provedení i Qt). Vygenerovaný kód zatím neobsahuje instrukce jako jsou prefetch/prefetchw a ukládání pomocí Non-Thermal hintu (movntq, movntdq, ...).

Při vlastních testech mi vychází, že operace CompositeOver a další kompozitní operace jsou asi o 50% rychlejší než ty, co jsou implementované v knihovně pixman/cairo. Při volení nestandardních formátů by rychlost měla být ještě lepší. Zkoušel jsem porovnávat i s knihovnou SDL a kompozitní operaci CompositeOver mám rychlostně podobnou. Problém je v tom, že SDL používá nepřesný výpočet (který zrychlí algoritmus až o 30%), takže to srovnání je spíš orientační.

Budoucnost

Knihovna je součástí moji diplomové práce, ve které se věnuji tématu návrhu a optimalizace grafické knihovny, která je schopná použít vlákna a jit kompilaci pro maximální efektivitu. Osobně by se mi nejvíce líbilo, kdyby se dala vytvořit podpora BlitJit například pro cairo, ale to by chtělo opravdu pořádné testování a doladění veškerých detailů, na které v současnosti není moc času;)

Odkazy

Testovací aplikace je v repozitáří BlitJit v adresáři trunk/BlitJitTest. Pro testování je potřeba modifikovat zdrojový kód (#ifdef, atd...), který je díky testování celkem nepřehledný :-)

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.