Opencl - криві руки чи бібліотека
Submitted by dvion on Mon, 07/11/2011 - 11:28
Вітаю. Програмую на ocl, вже довго страждаю з однією проблемою, яку зараз спробую викласти.
1. створюю контент, ініціалізую код і 1 головний буфер, розмір якого великий. 2. у кожному потоці, які є потоками із серверного сокету, я ініціалізую, завантажую, видаляю: свій кенел, малий буфер.
Таким чином, контент у мене константний, і головний буфер також. А в кожному потоці для підрахунку виведення даних створюється свій кенел, і буфер куди він скидає обчислення звідки бере вихідні дані.
Отже, суть проблеми: все добре, все працює чудово, тільки. При створенні буфера, кенела, його запуску НЕ З головного потоку, множаться хендли! Якщо робити те саме з головного потоку, то все окей! Тимчасово вийшов із ситуації переведенням у головний потік за допомогою sendmessage. Однак мені так не подобається робити, і хотілося б дізнатися, принаймні, де проблема. Одразу скажу, що дебаг займає вже не 1 день, і не 2 і не 3. А понад 6 місяців. За цей час вже оновлювався драйвер, але проблема так і не вирішилася.
Звичайно можна не створювати кенел багато разів, як я це роблю, шукати виходи типу sendmsg та іншого, але є конкретний нюанс, і хотілося б його вирішити. Крім того, якщо либа не потокобезпечна – то нехай так і пишуть (це просто думки вголос).
Отже, amdocl (тобто. від хроносу під АМД).
Загалом Хронос офіційно
Submitted by dvion on Wed, 07/13/2011 - 05:52
Загалом Хронос офіційно пояснив, що бібліотеки ocl не потокобезопасны. Що, мабуть, буде кінцевим вердиктом.
У нормальному вигляді, id потоку, що використовує контент, має бути id потоку, йогостворив. Інакше витік.
У сенсі, там на стеку
Submitted by lexa on Wed, 07/13/2011 - 13:36
У сенсі там на стеку щось зберігається? Начебто, нема чого бути на стеку.
Що буде, якщо я створю контекст і все інше (буфера, черги тощо), обкладу все це глобальним семафором, а буду користуватися з кількох потоків?
Submitted by dvion on Thu, 07/14/2011 - 18:31
То будуть множитись хендли, тому що ID потоку, з якого йде виклик, не буде дорівнює ID потоку, який створив контент.
Хочете – перевіряйте. І справа тут не в критичній секції та інше, а ось саме що в ID потоку. Сам уже дуже багато сил загубив, щоб зробити нормально.
А найцікавіше знаєте що (повість усім читачам)? Що є блокування буфера, виконання кенелів, все є. Зрозуміло, що іноді зручно асинхронно видалити за собою вже непотрібні об'єкти, але. Потокобезпека потрібніша річ, ніж різноманітність у тій чи іншій асинхронності тощо.
Ось так ось! Сумно, що навряд ситуація зміниться. Бо, як я вже тут згадав, офіційно пояснили, що "not thread safe" і все тут.
Якщо я працюю в Win, реалізував повідомленнями. Можна зробити свої повідомлення, можна виділити спеціальний трейд і зробити у ньому обробку всього необхідного, але. Мороки то! У цілому нині хороша, але цей факт трохи збентежив. Ну, нічого не залишається, доведеться так.
Дивна справа
Submitted by lexa on Thu, 07/14/2011 - 18:59
Дивна річ якась.
Ось в OpenCL 1.1, в апендиксі A.2 написано рівно протилежне: thread safe.
Submitted by dvion on Fri, 07/15/2011 - 06:47
Значить таки криві руки? Я якраз 1.1 версію і використовую. Те, що проблема є зараз - це факт,а щодо написів. Це на одному з форумів, не пам'ятаю АМД або Хроноса кинули посилання, потрібно копатися щоб знайти її і пред'явити тут як доказ.
З написами все просто: -
Submitted by lexa on Fri, 07/15/2011 - 08:38
З написами все просто: - напис про thread safety винесено в "короткий" список відмінностей OCL 1.1 - ну і апендикс A.2, де все написано ("за винятком SetKernelArg")
А ось життя може виявитися багатшим, причому купою способів: - у ATI в цьому місці проблема, а conformity tests її не знаходять - або, наприклад і банально, в path валяється opencl.dll старої версії.
Submitted by dvion on Sun, 07/17/2011 - 08:17
І так, про всяк випадок, все перевірив. І навіть трохи запропонованішого. Проблеми все також, знайшов ще одну.
1. По-перше залишається проблема розмноження хендлів, що при тривалій роботі так само призводить і до витоку пам'яті. Це відбувається, якщо робота з Command Quene пролягає не з того потоку, з якого ми її ініціалізуємо.
Рішення: використання synchronize, а також WM (windows messages), для передачі управління головному потоку. Так проблема вирішується.
2. Другий, страшніший баг: якщо в нас два пристрої, і в принципі ми хочемо працювати з ними в двох різних додатках, то. Не поспішайте. Через деякий час у ocl-драйвері відбудеться помилка. Від чого вона походить, я особисто не розбирався. Можна обкласти ассинхронну передачу команд м'ютексами, відповідно це супроводжується дещо відсотковим спадом продуктивності.
Однак краще реалізовувати роботу з девайсами з однієї програми, враховуючи особливості пункту 1.
PS термін збою драйвера у мене іноді складає пів дня, проте такий збій є.
__ Це всестосується OCL 1.1.
"З написами все просто:" - все, та не дуже просто. На паркані теж написано. Наприклад, не хочу здатися грубим, але більшість користувачів OCL в різних середовищах програмування, і не помітять хендли, що втікають помаленьку в "нікуди". Крім того, якщо запуск здійснюється "одноразово" - це ще складніше.
"напис про thread safety винесено в "короткий" список відмінностей OCL 1.1" - винесено, проте не один я розорився щодо даних проблем. На англомовних форумах про це вже не один пост пісан.
"У ATI у цьому місці проблема, а conformity tests її не знаходять" - це не проблема ATI. Це проблема підходу до пошуку драйвера. Спочатку роутера OpenCl.dll не було, і доводилося вручну вибирати ocl. На даний момент цього не потрібно, звідти й проблема.
Ну от, начебто, і все. Сподіваюся в OCL 1.2 обставини зміняться.
Ага дякую. Практика
Submitted by lexa on Sun, 07/17/2011 - 12:03
Ага дякую. Практика – критерій істини.
Якщо у вас утворився компактний тестуючий код (тобто без вашої специфіки) – було б чудово, якби він раптом з'явився у загальнодоступності.
Submitted by dvion on Sun, 07/17/2011 - 13:21
Без проблем, а який саме код потрібний? Тикання пальцем у витік?
Ну як то так. Щось таке,
Submitted by lexa on Sun, 07/17/2011 - 21:42
Ну як то так. Щось таке, що працює, а потім каже "я зіпсувалося". Вже не знаю, як йому це вдасться і чи вдасться взагалі, але ви якось проблему детектували.
Такий приклад треба, природно, пхати у всі місця (Хронос та їхній форум, ATI та їхній форум, якщо на Інтелі є порча – то й туди).
Так, і до речі, якщо буде
Submitted by J0hn on Wed, 07/20/2011 - 22:13
Так, ідо речі, якщо буде невеликий test-case, мені не важко буде його перевірити на windows і linux (nvidia), і якщо проблема виявиться і в мене, то я можу теж у саппорт запостити. Скажімо так, мені прямий зараз OpenCL не потрібен, але в майбутньому може знадобитися - і хотілося б щоб поменших проблем було.
Те що у NVidia з їх OpenCL
Submitted by lexa on Thu, 07/21/2011 - 08:38
Те що у NVidia з їх OpenCL 1.0 є проблеми з thread-safe - це "давно відомо", щонайменше у форумах про це писали. Ну так о 1.0 і не обіцяв ніхто.
А 1.1 ще не
Submitted by J0hn on Thu, 07/21/2011 - 09:05
А 1,1 ще не зарелізували? Дивлюся в опис останнього драйвера - і правда 1.0 (http://www.nvidia.ru/object/winxp-275.33-whql-driver-ru.html) .ru/object/cuda_opencl_new_ru.html ) пререліз був аж рік тому.
У Nvidia – ні, не
Submitted by lexa on Thu, 07/21/2011 - 11:16
У Nvidia – ні, не зарелізували. 1.0 є у всіх нових драйверах, а 1.1 так і залишився тільки в тому (258, здається).
Чому воно так – я не знаю, але у технічні складнощі, які не можна було б вирішити за рік – не вірю. Підозрюю якийсь marketing bullshit "якщо ми підтримаємо хороший загальний OpenCL, то це може вбити CUDA".
Підозрюю якийсь marketing
Submitted by J0hn on Thu, 07/21/2011 - 11:24
Підозрюю якийсь marketing bullshit я щось таке чув (тільки не щодо 1.1, а просто про nvidia і opencl).
1. у кожному потоці, які
Submitted by J0hn on Thu, 07/21/2011 - 09:32
1.у кожному потоці, які є потоками із серверного сокету, я ініціалізую, завантажую, видаляю: свій кенел, малий буфер. 2.Під час створення буфера, кенела, йогозапуску НЕ З головного потоку, множаться хендли! 3.Звичайно можна не створювати кенел багато разів, як я це роблю
Проблему у вас у якому разі? Коли викликається kernel з потоку що його не створював? І що означає "множаться хендли"? Які хендли, як це виявляється?
Ось відкрив я специфікацію (http://www.khronos.org/registry/cl/specs/opencl-1.1.pdf#page=368), і прямий на початку параграфа "A.2 Multiple Host Threads" написано:"All OpenCL API Calls є thread-safe^78 except clSetKernelArg. clSetKernelArg є безпечний для дзвінка з будь-якого дня, і є надійний для проведення дзвінків повторно-завчасно з тривалим поточним телефонним режимом на різних cl_kernel об'єктів. However з object_cl_kernel є невизначеним, якщо clSetKernelArg є повідомлений від декількох host threads on the same cl_kernel object at the same time^79" виноска 79:"There is inherent race condition in the design of OpenCL що висловлюються між керуючим argumentом і використовуючи кернал з ClEnqueueNDRangeKernel or clEnqueueTask. ued Rather than attempt до share cl_kernel об'єкти серед multiple host threads, applications are strongly encouraged to make additional cl_kernel objects for kernel functions for each host thread."
Це бува не ваш case?
"Проблему у вас у якому
Submitted by dvion on Sat, 07/23/2011 - 05:41
"Проблему у вас у якому разі? Коли викликається kernel з потоку який його не створював?"
- Взагалі будь-які дії з OCL 1.1 не з того потоку, з якого будь-що створені призводять до розмноження хендлів.
- У тому числі навітьпросте створення буфера.
"І що означає "множаться хендли"? Які хендли, як це виявляється?"
- Що таке handle у windows можна прочитати, ввівши в пошуковику. Сенс у тому, що хоч втрата і невелика, але пам'ять за пару днів безперервної роботи таки під'їдається (дуже багато обчислень).
Ще одна не менш важлива проблема, що не стосується мультипоточності - це використання двох пристроїв.
З цим же алгоритмом один пристрій працює добре протягом тижнів!
І ще один бажок. Стосується AMD ocl 1.1. Якщо під час обчислення GPU включити mpeg-файл (мпег має апаратну підтримку) - комп'ютер зависає геть.
Я звичайно розумію, що якщо обчислюєш на машині, ролик всерйоз не включатимеш, але чому так суворо?
- Баг. Хочете - перевірте: запустіть будь-який алгоритм та увімкніть mpeg ролик.
"І що означає "множаться
Submitted by J0hn on Sat, 07/23/2011 - 10:31
"І що означає "множаться хендли"? Які хендли, як це виявляється?" - Що таке handle у windows можна прочитати, ввівши в пошуковику. Сенс у тому, що хоч втрата і невелика, але пам'ять за пару днів безперервної роботи все-таки під'їдається (дуже багато обчислень). Що таке хендли я знаю. Вони можуть використовуватися не тільки самих windows. Як саме ви діагностуєте розмножуваність хендлів(у вашому випадку як я зрозумів хендлів windows)?
Загалом test case на
Submitted by J0hn on Sat, 07/23/2011 - 17:33
Загалом test case на хендли, що розмножуються, в студію.