OpenCL clEnqueueTasks Parallelism

Ik probeer een code te schrijven die AES Decryption doet. Ik heb de code werkend maar ik wilde Cipher Block Chaining kunnen toevoegen, wat vereist dat ik een XOR-bewerking na de decodering doe.

Om de code gemakkelijker te kunnen schrijven en begrijpen heb ik de code geschreven met behulp van twee kernels. Een die de decodering uitvoert op een enkel blok en een die de XOR uitvoert voor het CBC-deel. Vervolgens stuurde ik deze via clEnqueueTask naar de wachtrij voor elk 16byte-gegevensblok met de afhankelijkheid die is opgegeven door een gebeurtenis tussen de decodering en XOR.

Dit blijkt erg traag te zijn, het werkt in het feit dat het ze in de juiste volgorde doet, maar het lijkt niet de uitvoering parallel te lopen.

Weet iemand waarom of hoe de prestaties te verbeteren zonder de granulariteit te verliezen?

1
Merk op dat deze functie in versie CL1.2 gedeprecieerd is en vervangen moet worden door relevante aanroep van een rangeND kerneloproep ( stackoverflow.com/questions/36816301/… )
toegevoegd de auteur StarShine, de bron

2 antwoord

clEnqueueTask is typically used for single-threaded tasks.

Als uw kernels parallel kunnen worden uitgevoerd, gebruikt u één clEnqueueNDRangeKernel bellen in plaats van veel clEnqueueTask -aanroepen met verschillende parameters.

Iets anders dat goede parallelle prestaties zou kunnen voorkomen, is veel toegang tot het wereldwijde geheugen. Als je in je kernel veel reads/writes van globaal geheugen doet vergeleken met de hoeveelheid berekening, dan zou dat je misschien vertragen, afhankelijk van je hardware.

1
toegevoegd

De kernel die via clEnqueueTask wordt uitgevoerd, heeft in wezen één thread, wat betekent dat de globale werkgrootte 1 is en dat de taak een hele rekeneenheid inneemt voor deze enkele thread. Dit kan van grote invloed zijn op de prestaties, want op een typische GPU kunt u 8-16 taken/werkgroepen parallel uitvoeren (CL_DEVICE_MAX_COMPUTE_UNITS) en in een werkgroep 256-1024 uitvoeren (CL_DEVICE_MAX_WORK_GROUP_SIZE). In uw geval kunt u dus 8-16x parallellisme bereiken in plaats van de theoretische maximumwaarde van 15000x, omdat u niet de hele hardware kunt gebruiken.

0
toegevoegd