About Me

Michael Zucchi

 B.E. (Comp. Sys. Eng.)

  also known as Zed
  to his mates & enemies!

notzed at gmail >
fosstodon.org/@notzed >

Tags

android (44)
beagle (63)
biographical (104)
blogz (9)
business (1)
code (77)
compilerz (1)
cooking (31)
dez (7)
dusk (31)
esp32 (4)
extensionz (1)
ffts (3)
forth (3)
free software (4)
games (32)
gloat (2)
globalisation (1)
gnu (4)
graphics (16)
gsoc (4)
hacking (459)
haiku (2)
horticulture (10)
house (23)
hsa (6)
humour (7)
imagez (28)
java (231)
java ee (3)
javafx (49)
jjmpeg (81)
junk (3)
kobo (15)
libeze (7)
linux (5)
mediaz (27)
ml (15)
nativez (10)
opencl (120)
os (17)
panamaz (5)
parallella (97)
pdfz (8)
philosophy (26)
picfx (2)
players (1)
playerz (2)
politics (7)
ps3 (12)
puppybits (17)
rants (137)
readerz (8)
rez (1)
socles (36)
termz (3)
videoz (6)
vulkan (3)
wanki (3)
workshop (3)
zcl (4)
zedzone (26)
Wednesday, 10 November 2010, 08:59

OpenCL scheduling

I was playing around over the last couple of days with adding extra work queues to the OpenCL application i've been working on for work. Up until this point I was using a single queue referenced off a central 'context' object, which has worked ok, but I had to add some longer-running background processing steps which don't fit into the rest of the application.

I noticed one weird thing - I have two separate processes, one of which (say) takes 5 seconds to run, the other 6. If I run process 1 and 2 at the same time (on separate queues), process 1 takes about 6 seconds to run but process 2 blows out to 25 seconds. If I run two lots of process 1 then they both take about 10 seconds to execute.

I suspect it is because although they execute in about the same amount of time, process 1 is made of fewer steps and the scheduler is just alternating through the jobs in function-call sequence and so a lot more of process 1 gets run when process 2 is also active. Although it doesn't matter at this point it could be a significant problem in a 'real' application.

They are both run on a separate thread and throw out a lot of queue.finish()'s as well - mostly so it can detect user cancellation without queuing up too much work, but also because it seemed to run into resource problems if I queued up thousands of function calls at once (the over-all processing time is important but the interaction is more important at this point). So that also might be affecting the scheduling time. This is on NVidia.

I also found a bug in JOCL and filed another bug on the jogamp bugzilla - the 3rd JOCL bug there, and the 3rd i've filed myself. Hmmm.

Tagged opencl.
A shed of my own. | Video
Copyright (C) 2019 Michael Zucchi, All Rights Reserved. Powered by gcc & me!