Dotaz: OpenCL, nVidia a OUT_OF_HOST_MEMORY

[mess]

Mám takový menší problém s OpenCL. Při pokusu o inicializaci mi fce. clCreateContext vrací chybu CL_OUT_OF_HOST_MEMORY. Toto se děje nahodile - někdy to funguje, někdy ne. Následuje příklad kódu, který demonstruje popisovaný problém. Pokud se všechno povede podle očekávání, pak by měl program vypsat "ErrorCode:0", pokud se něco podělá, tak vypíše "ErrorCode:-6". Netušíte někdo, co dělám špatně? Mám nVidiu Quadro NVS140M.

#include <CL/cl.hpp>

void main(){
  cl_platform_id platform;
  clGetPlatformIDs(1, &platform, 0);
  cl_device_id device;
  clGetDeviceIDs(platform, CL_DEVICE_TYPE_DEFAULT, 1, &device, 0);
  cl_context_properties props[] = {
    CL_CONTEXT_PLATFORM,
    (cl_context_properties)platform,
    0
  };
  cl_int err = 0;
  cl_context context = clCreateContext(props,1,&device,0,0,&err);
  cout << "ErrorCode:" << err << endl;
}

---

---

Odpovědi

[mess]

Ještě poznamenám, že RAM mám 4GB + cca 7GB swap, takže o paměť by nouze být neměla. A htop hlásí, že je ještě cca 1GB fyzické RAM prázdný a ve swapu je 200MB nějakého shitu, ale nic kritického.

[stativ]

Na stackoveflow kdosi řeší podobný problém a tomu to sežere 45 GB ve VIRT. Zřejmě ale jde o podivný trik, aby CUDA (OpenCL na nVidii bude určitě používat stejné cesty) mělo jednotný systém adres pro adresování hosta i GPU.

Já bych to viděl na špatné uvolňování zdrojů, a to buď na tvé straně, nebo na straně ovladače. Možná by pomohl valgrind.

[Jardík]

Já ti nepomůžu, jenom musím povzdechnout nad tím, že teď vím o další knihovně, kde si z nějakého důvodu museli vycucat nové číselné typy a zesrat tak jakoukoliv kooperativu s knihovnami používající standardní celočíselné typy. Proč musí proboha každá debilotina mít svůj vlastní typ int. Na khronos.org je popsán jako A signed two's complement 32-bit integer. Z nějakého důvodu jim ale mozek nedovolil použít int32_t? Pokud na takové platformě totiž opencl běží, takový typ snad musí existovat a tedy int32_t bude taky existovat. Ale né, za každou cenu budeme nutit uživatele používat vlastní datové typy, aby kód byl za každou cenu co nejnepřehlednější a zprasený.

Takové API by snad ani nikdo neměl používat a OpenCL bojkotovat a najít si alternativu. Fůj.

[l4m4]

Kvízová otázka: ve které verzi C++ standardu je int32_t?

[Jardík]

Kdo hledá, najde ^-^

[l4m4]

Ale neboj, já odpověď znám. Zato ty se nějak zdráháš ji přiznat.

[Jamaic]

Oni nejspíše používají vlastní datové typy, neb číselná reprezentace na GPU může být rozdílná od CPU.

[Jardík]

Neb číselná reprezentace int32_t a cl_int je podle popisu shodná.

[stativ]

A proto budeme nutit uživatele pamatovat si, které datové typy jsou shodné se standardem (a jakým? v POSIXu to není) a které ne. A taky které ze „standardních“ typů jsou OpenCL podporovány (hint – double nemusí existovat přinejmenším u OpenCL 1.0).

[Jamaic]

To že podle popisu dělají to samé neznámená že v paměti budou stejně zapsané.

Viz. "Přímý kód", "Doplňkový kód", atd.

[Jardík]

Tady je asi fakt někdo mimo.

[l4m4]

Ano.

[stativ]

Protože GPU není CPU?

[Jardík]

A to s tím souvisí jak?

[mess]

No, třeba je fajn moct pracovat s datovými typy, které jsou stejné na CPU i na GPU bez nutnosti nějakých převáděcích harakiri. A jinak díky, že se věnujete tématu dotazu.

[Jardík]

A jak je jiný int32_t od toho typu na GPU, který je popsán jako A signed two's complement 32-bit integer? Pokud takový typ existuje, musí int32_t v stdint.h být. Pokud neexistuje, těžko by bylo možné vytvořit C API pro takové GPU. Ale ok, už mlčím, jenom musím prudit, protože to občas pomáhá, někdo si toho všimne a pak třeba upustí od kravin, že si bude definovat vlastní celočíselné typy pro každou kravinu.

[stativ]

Protože GPU může mít (a má) své vlastní datové typy (třeba 16bitový half) a s ohledem na výkon nemá smysl řešit případnou nutnost konverzí (no, v případě přesunů halfu CPU - GPU nutná je). Mít polovinu typů nadefinovanou podle OpenCL a polovinu pomocí „standardních“ typů jako je uitn32_t je IMHO ještě mnohem větší bordel.

[stativ]

Tohle asi nebylo úplně šťastné vyjádření, s OpenCL jsem už nedělal víc než rok. Když nad tím přemýšlím, tak to u C API pro OpenCL bude spíš z důvodu a) jednotnosti, b) znalosti, že daný typ půjde dobře překonvertovat na to, s čím pracuje OpenCL kernel

[Jamaic]

Neběží ti na počítači nějaká graficky akcelerovaná aplikace? (hra, 3D modelovací program, DWM, ...)

Mimochodem, ty si vytvoříš "context" přez clCreateContext ale potom ho přez clReleaseContext neuvolňuješ. Takže máš v aplikaci memoryleak, který ti nejspíš způsobuje tuhle chybu.

[mess]

O ten clReleaseContext nejde, používám C++ bindings, tam se to řeší v destruktoru příslušné třídy, dával jsem sem jen minimální příklad.

Jinak máš recht, běží mi tu KWin se zapnutými kompozitními efekty. Ale pochopil bych, kdyby to selhalo pokaždé, ne jen nahodile. Navíc, když si pomocí clGetDeviceInfo nechám zjistit, jestli je zařízení dostupné, tak mi vrací vždycky true.

Teď jsem zjistil zajímavou věc a sice, že asi záleží na velikosti volné fyzické RAM. Zavřel jsem Firefox a rozjelo se to. Nicméně i s tím Firefoxem jsem měl cca 500MB RAM volné, tak moc nechápu, na co to potřebuje tolik paměti.

[stativ]

Napadá mě, jestli to nebude chtít třeba stejné množství paměti jako je velikost paměti GPU, aby šlo udělat 1:1 mapování mezi GPU a RAM.

[Jamaic]

OS by měl být schopen namapovat virtuální adresu na paměť, který má v sobě grafická karta. Takže by ti to fyzicky nemělo zaplňovat RAM.

Spíš bude problém s tím, že Firefox má v sobě zabudovanou podporu pro akceleraci pomocí grafické karty, tudíž se to s tvým programem může hádat.

[mess]

Podle toho, co zatím pozoruju, tak to závisí na dvou faktorech:

1. Velikosti volné RAM (pokud mám míň, než cca 500MB volné, tak to začne blbnout - moje GK má 512MB vlastní RAM, takže to fakt vypadá, jako by si to dělalo nějaký buffer pro komunikaci. Otázkou zůstává, proč do pekla?)
2. Zapnutí/vypnutí kompozitních efektů v KWin (asi se to bije, nebo já nevím).

Zrovna teď mám v KWinu vypnuté efekty, mám zapnutý FF, RAMky je volné cca 2GB a funguje to.

[mess]

Tak ještě jeden poznatek - bije se to asi Flashem. Zapnu Youtube - nefunguje, vypnu Youtube - funguje. Tento jev dokážu vyvolat spolehlivě Vypnul jsem HW akceleraci Flashe a vypadá to, že zatím všechno v pohodě.

[mess]

Takže abych to shrnul. Vypadá to, že implementace OpenCL na nVidii vyžaduje tyto dvě podmínky:

1. Velikost volné RAM musí být aspoň taková, jako velikost paměti na zvoleném zařízení (nevím, proč).
2. Nesmí být zrovna spuštěná žádná aplikace používající HW akceleraci přes zvolené zařízení (správce oken s kompozitními efekty, Flash, přehrávač filmů používájící HW akceleraci ...).

Snad to někomu pomůže.

[chrono]

Kompozitné efekty, aspoň u mňa, nevadia (môže to ale súvisieť s voľnou pamäťou CPU/GPU).