{"id":2554,"date":"2017-11-19T20:40:21","date_gmt":"2017-11-19T20:40:21","guid":{"rendered":"http:\/\/www.colorwave.it\/blog\/?p=2554"},"modified":"2018-01-29T06:25:45","modified_gmt":"2018-01-29T06:25:45","slug":"gpu_mem_object","status":"publish","type":"post","link":"https:\/\/www.colorwave.it\/blog\/framework\/gpu_mem_object\/admin\/2017\/11\/","title":{"rendered":"gpu_mem_object"},"content":{"rendered":"

La gpu_mem_object<\/em> \u00e8 la classe base di gestione degli oggetti di memoria creati su un context OpenCL:\u00a0 da essa derivano tutte le classi di\u00a0 i\/o di dati verso i kernel; gpu_mem_object<\/em>\u00a0 gestisce alcune propriet\u00e0 comuni e definisce le funzioni virtuali, che possono essere riscritte per le classi derivate.<\/p>\n

Perch\u00e8 questa classe?<\/h4>\n

la definizione del passaggio di parametri ad un kernel pu\u00f2 essere particolarmente complesso, dovendo spesso trasferire e\/o ricevere dati la cui sequenza pu\u00f2 essere onerosa da gestire; le classi derivate da\u00a0gpu_mem_object <\/em>sono state progettate per standardizzare le modalit\u00e0 di i\/o su un kernel, quando le informazioni gestite dalle classi sono usate frequentemente in molti differenti kernel; ad esempio la classe gpu_lut_rgb<\/em> definisce un modo standardizzato per trasferire ad un kernel tutte le informazioni (in questo caso numero di elementi nella lut, numero di indici e dimensioni degli elementi); Vedremo che il trasferimento al kernel viene effettuato attraverso una funzione virtuale Push_kernel<\/em>, prima dell’esecuzione dello stesso. Baster\u00e0 quindi, per ciascuna classe derivata riscrivere questa funzione e documentarne la sequenza di parametri generata nel commento.<\/p>\n

\/** \\brief classe prototipo di tutti gli oggetti memoria di opencl\r\n*\/\r\nclass AFX_EXT_CLASS gpu_mem_object\r\n{\r\npublic:\r\n\tgpu_mem_object ( );\r\n\tvirtual ~gpu_mem_object ( );\r\n\r\n\t\/** assegna l'handler opencl\r\n\t*\/\r\n\tvoid Set_id ( cl_mem _cl_mem );\r\n\r\n\t\/** rimanda l'handler opencl\r\n\t*\/\r\n\tcl_mem Get_id ( );\r\n\r\n\tvoid Set_kernel ( class gpu_kernel *kernel );\r\n\tgpu_kernel *Get_kernel ( );\r\n\r\n\t\/** \\brief definisce i flag di modalit\u00e0 memoria gpu gestita\r\n\t\\details CL_MEM_READ_ONLY.. etc\r\n\t*\/\r\n\tbool Set_mem_flags ( cl_mem_flags mode );\r\n\r\n\t\/** \\brief rimanda i flag di modalit\u00e0 memoria gpu gestita\r\n\t*\/\r\n\tcl_mem_flags Get_mem_flags ( );\r\n\r\n\t\/** \\brief rimanda il puntatore alla memoria allocata nella CPU\r\n\t*\/\r\n\tvirtual void *Ptr ( );\r\n\r\n\t\/**  quantit\u00e0 di memoria assegnata al puntatore\r\n\t*\/\r\n\tvirtual size_t Bytes ( );\r\n\r\n\t\/** \\brief trasferisce i dati dell'oggetto al kernel \r\n\t\\details la  funzione \u00e8 virtuale e deve essere ridefinita per ciascun oggetto derivato\r\n\til kernel che riceve la struttur\u00e0 sar\u00e0 ovviamente scritto in modo\r\n\tda intercettare correttamente i parametri passati per\r\n\tciascuna classe.\r\n\tFare riferimento alla descrizione di ciascuna classe derivata per la conoscenza\r\n\tdei parametri trasferiti al kernel\r\n\r\n\t\\param kernel se ==0 trasferisce \u00e8 il kernel dove trasferire, altrimenti usa il kernel assegnato\r\n\r\n\t\\return true se informazione da trasferire correttamente definita\r\n\t*\/\r\n\tvirtual bool Push_kernel(gpu_kernel *kernel=0);\r\n\r\n\tpublic: _gpu_object_code c_gpu_mem;\t\/\/ codice oggetto memoria assegnato\r\n\r\n\t__use_private_struct\r\n};\r\n<\/pre>\n
Set_id\u00a0 e Get_id<\/h4>\n
Le due funzioni permettono di assegnare e ottenere l’handle\u00a0 \u00a0cl_mem ottenuto da OpenCL quando viene creato un oggetto di memoria (buffer, immagine etc) ; ricordiamo che un oggetto\u00a0 di memoria \u00e8 sempre creato e assegnato a un gpu_context ; i<\/em>n particolare la funzione Set_Id() \u00e8 usata internamente dalla gpu_context quando viene richiesta la creazione di un qualunque oggetto\u00a0gpu_mem_object, <\/em>pertanto non deve essere normalmente utilizzato dalle classi derivate.<\/p>\n
Set_kernel<\/h4>\n
Definisce il gpu_kernel al quale sar\u00e0 trasferito l’elemento\u00a0gpu_mem_object.\u00a0<\/em>Vedremo in un prossimo articolo come e dove utilizzare questa funzione.<\/p>\n
\"\"<\/p><\/div><\/div>\n
Il kernel assegnato con questa funzione \u00e8 quello di default; vedremo che comunque sar\u00e0 possibile passare l’oggetto gpu_mem_object<\/em> a pi\u00f9 kernel da eseguire in parallelo.<\/p>\n
Get_kernel<\/strong><\/h4>\n
rimanda la classe gpu_kernel che \u00e8 stata assegnata di default;<\/p>\n
Set_mem_flags e\u00a0Get_mem_flags<\/h4>\n
Le due funzioni, gestite internamente al gpu_context definiscono le modalit\u00e0 di gestione dell’oggetto passato al kernel; i valori sono quelli assegnabili al tipo\u00a0 enumerato cl_mem_flags (CL_MEM_READ_ONLY CL_MEM_WRITE_ONLY.. etc). Per una lista completa dei valori dei tipi enumerati di OpenCL leggere qui<\/a>.<\/p>\n
virtual <\/span>void<\/span> *<\/span>Ptr<\/span><\/h4>\n
Rimanda il puntatore alla memoria allocata\/assegnata nella classe; La funzione \u00e8 virtuale, poich\u00e9 le classi derivate devono poter gestire dati e schemi di memoria differenti; la classe base gpu_mem_object rimanda 0, poich\u00e8 non \u00e8 deputata a gestire direttamente i puntatore, ma fornisce lo schema per le classi derivate.<\/span><\/div>\n
virtual size_t Bytes<\/h4>\n
Rimanda la quantit\u00e0 in bytes allocata con il puntatore rimandato da Ptr(); Come la funzione Ptr(), anche la Bytes() pu\u00f2 essere usata per accedere, quando necessario, alla memoria di i\/o sul kernel; ad esempio si pu\u00f2 accedere alla memoria di un oggetto modificato dal\u00a0 kernel (ad esempio la memoria di in oggetto IMAGE passato al kernel utilizzando la gpu_image_2d..)<\/p>\n
virtual bool Push_kernel<\/h4>\n
La funzione, riscritta per ciascuna classe derivata da gpu_mem_object, ha il compito di trasferire le immagini nella coda del kernel; vedremo in seguito un esempio di costruzione di questa funzione; Notare che il kernel di esecuzione passato alla funzione pu\u00f2 essere diverso da quello dichiarato di default; in questo caso ci si aspetta che il nuovo kernel (o i nuovi..) sia in parallelo con quello di default;<\/p>\n
\"\"<\/p><\/div><\/div>\n
Il kernel passato per default \u00e8 stato definito per semplificare la scrittura dei programmi da eseguire su OpenCL: il gpu_context di allocazione dei gpu_mem_object deve necessariamente essere lo stesso per tutti i kernel, quindi verr\u00e0 ricavato dalla prima assegnazione, ricavandolo dal primo gpu_kernel. Il pi\u00f9 delle volte succeder\u00e0 di definire programmi che usano un solo kernel o li usano in modo sequenziale; in questo caso vedremo che questa strategia di scrittura favorisce la concisione,\u00a0 nascondendo molti passaggi e chiamate a funzioni OpenCL che altrimenti dovrebbero comunque essere effettuate.<\/p>\n
 <\/p>\n","protected":false},"excerpt":{"rendered":"
La gpu_mem_object \u00e8 la classe base di gestione degli oggetti di memoria creati su un context OpenCL:\u00a0 da essa derivano tutte le classi di\u00a0 i\/o di dati verso i kernel; gpu_mem_object\u00a0 gestisce alcune propriet\u00e0 comuni e definisce le funzioni virtuali, che possono…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"aside","meta":{"_acf_changed":false,"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"footnotes":"","_jetpack_memberships_contains_paid_content":false,"jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false},"version":2}},"categories":[19,29,108],"tags":[],"jetpack_publicize_connections":[],"acf":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9rwsf-Fc","jetpack_likes_enabled":true,"jetpack-related-posts":[],"_links":{"self":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/2554"}],"collection":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/comments?post=2554"}],"version-history":[{"count":15,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/2554\/revisions"}],"predecessor-version":[{"id":2570,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/posts\/2554\/revisions\/2570"}],"wp:attachment":[{"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/media?parent=2554"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/categories?post=2554"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.colorwave.it\/blog\/wp-json\/wp\/v2\/tags?post=2554"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}