Advertisement
real_het

devguru letter

Apr 18th, 2013
157
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.42 KB | None | 0 0
  1. Thank you all your feedbacks. I can't wait to try those on the weekend.
  2.  
  3. Until that TODO:
  4. LeeHowes, vmiura: atomic in the while()
  5.  
  6. "Workgroups are scheduled in batches on the GPU. So, Workgroups in Batch-1 can be infintely spinning waiting for other Batches to complete. The other batches dont get scheduled until Batch-1 completes and thats a classic deadlock."
  7. Yea, I'm dealing with this:
  8. - Simply don't let the number of WorkGroups go above 2*NumberOfCUes. (tho' it's weird that it didn't crashed at CU*2+1)
  9. (On GCN I could use the s_sleep() instruction to let other waves increment and poll that flag. And have 'complete path' with the glc flat that drallan mentioned earlier)
  10.  
  11. This time, the bottleneck is LDS memory and not the processing power, so I hope if I will not use that many waves, ther will be no deadlocks.
  12.  
  13. The program I wanna make will simulate waves in the strings of a virtual piano. It's basically like a 2D elastic water surface effect but in 1D, and on 192K frames per sec . That's why LDS is needed as a somewhat randomly accessible and fast memory.
  14. The synchronization will be used to let all the piano strings give and receive vibrations to and from each other when the sustain pedal is pressed (still on 129KHz).
  15. I already did a simulation for 3..6 strings (thats only 1-2 keys pressed) on a single Phenom II 3GHz core with the help of SSE, but I want all the 200+ strings burn simultaneously on a 1..2TFlops GPU .
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement