i.MX6 SDMA - assembler/disassembler (diskuse)

[vlastikroot]

Ja delam na i.MX5 a mam problem s grafikou, s VSYNC synchronizaci Qt/QML aplikace (prez EGLFS, bez X). Neni SDMA nejak v tom zapleteno? Zaboha nemuzu prijit na to, jak a cim se kopiruji snimky z GPU3D do framebufferu IPUv3. OpenGL driver je blob. Potreboval jsem podporu HW rotace displaye, tak jsem ji dodelal do toho IPUv3 driveru, ale nedari se mi to sesynchronizovat.

[zuzanak]

Můžu s určitou mírou jistoty mluvit jen o i.MX6 a podle ref. manuálu a jmen SDMA skriptů si myslím, že s přesunem snímku mezi GPU3D a IPUv3 SDMA skripty nesouvisí.

Jinak rotaci v IPUv3 jsem implementoval taky, a neobešlo se to bez patchů do jádra. Při alokaci paměti pro FB alokuji jeden blok paměti navíc. Do nového (rotačního) bloku paměti provádím rotace z původního bloku paměti. Synchronizuji to brutálně v user-space programu, který k tomu používá ioctl MXCFB_WAIT_FOR_VSYNC a double buffering na rotačním bufferu pomocí funkce mxcfb_pan_display, kterou měním offset zobrazovaného FB.

Co se týče OpenGL na i.MX6 v X11, tak tam jsem nabyl dojmu, že to není možné nakonfigurovat tak, aby vsync byl 60Hz, pravděpodobně něco ve zmiňované blobové OpenGL implementaci. Zajímavé je že při použití directfb to problém nebyl.

[vlastikroot]

Wait for sync jsem zkousel, ale to mi blokuje thread. Jak spoustis tu rotaci v IPUv3? Mam taky alokovany vstupni a vystupni buffer, ale nevim jak to nastavit, aby se po syncu displaye pustila ta rotace. Ted to poustim prasacky interruptem - to jsem okoukal z V4L driveru. Docela by se mi hodilo nahlidnout do tveho reseni.

Wait for sync je pro me nevhodny, zkousel jsem to, potrebuju aby thread bezel.

[zuzanak]

Rotaci spouštím pomocí ioctl IPU_QUEUE_TASK ovladače FB, volám jej po čekání na vsync. Protože jsem pouze autorem řešení, ale už ne jeho vlastníkem, dám vědět v pondělí, zda to budu moci zveřejnit. Já osobně s tím nemám žádný problém.

Patch do jádra se aplikuje na linux-3.0.35 a v něm na soubory:

• linux-3.0.35/drivers/video/mxc/mxc_ipuv3_fb.c
• linux-3.0.35/include/linux/mxcfb.h

To jen pro info, zda to vůbec budeš moci nějak použít.

K tomu mám program, který když je spuštěný tak rotuje celý FB nezávisle na tom kdo do něj kreslí. Blokování vlákna čekáním na vsync mi nevadí, protože celý proces dělá jen rotaci.

[vlastikroot]

To info mi staci, dekuji za pomoc Mam jadro 2.6.35. Ja prave rotaci poustim uvnitr driveru, aby se framebuffer choval stejne jako bez rotace. Uz jsem si udelal i LD_PRELOAD jako hook do OpenGL knihovny na swapBuffers, jen nevim, jak donutit OpenGL kreslit do druheho bufferu (abych mel input double buffer). Kdyz buffer prepnu pomoci toho mxcfb_pan_display pred spustenim OpenGL aplikace, tak pouziva novy buffer, ale kdyz to delam v tom hooku, tak to nema vliv (takze predpokladam ze to adresu/offset zjistuje pri startu a pak uz ne). Cekal bych, ze tam bude nejaky parametr kterym se double buffering zapne, nebo tak neco.

[Roman Došek]

Člověče musím obdivovat tvoji vynalézavost při řešení problémů. Kdybych na něco podobného narazil já, pravděpodobně bych zkusil cestu spíš cestu s NDA a podporoou Freescalu než psaním vlastního assembleru/disassembleru.

Na druhou stranu, každé moje setkání s Freescalama mě utvrzuje ve vůli se jim příště vyhnout. Zastaralé out-of-tree patche pro podporu procesorů, binární bloby nutné pro grafiku, mizerná dokumentace, ... Celkem by mě zajímal tvůj pohled na tuhle problematiku, je vůbec dneska kam sáhnout jinam? Na menší projekty se na multimediální procesory od Qualcommu nebo MediaTeku nedá vůbec sáhnout, NXP sfúzovalo s Freescalem, Ti se z trhu stáhnul... Mám dobré zkušenosti s Tegrama, ale cenově se to pohybuje úplně jinde..

[zuzanak]

Nabyl jsem při čtení diskuzí s podporou Freescalu dojem, že by komunikace s nimi mohl být běh na delší trať. Kdyby se řešení reverzním inženýrstvím protahovalo, asi by jsem je musel kontaktovat, a zkusit z nich dostat nějaké užitečné informace/nástroje.

Binárních blobů všeho druhu tam mají hodně, a to se nám taky moc nelíbí. Co se týče dokumentace, tak v dokumentaci k i.MX6 (5789 stránek) jsem našel zatím vše co jsem hledal, a připadala mi srozumitelná podobně jako dokumentace třeba od TI.

Kam sáhnout ti bohužel neporadím, já pracuji s tím co dostanu do ruky, a nemám moc žádný přehled co se ostatních výrobců týče. Vím jen, že Tegra byla alternativou k i.MX6, ale nějak (asi kvůli ceně) z toho sešlo. V minulosti jsem dělal s TI, ale to byly jen jednoduché mikroprocesory u kterých žádný problém nebyl.

[RM]

Pěkné, díky za zajímavý zápisek a odkaz. (Trochu se opakuju, ale co.)

[zuzanak]

Klidně se opakuj, pochvalou mě neurazíš.