TDR transparent managment RRS feed

  • Question

  • I love AMP and I plan to use it more and more, but there is one major drawback that is keeping us from using it in commercial code.  The management required to avoid TDRs in parallel_for_each code is so complex that we sacrifice readability and maintainability, and also stability.

    To reduce the risk of TDRs, we have to divide our task into multiple parallel_for_each loops.  This is further complicated by the fact that it is not possible to create an array view with a lower and upper index.  We have to create multiple array views that contain different parts of the same data.  This requires some exotic, and difficult code.

    I would like to suggest the following changes in a future version of AMP:

    Array views should support a lower index, so you can work on Array indexes 500-1000, for example, without creating a new array view.

    The Parallel_for_each call should have an overload for transparently handling splitting tasks into chunks that allow the GPU to multitask between chunks.

    Friday, June 20, 2014 9:41 PM

All replies

  • Hello Dan.

    Thank you for the feedback (and fighting the good fight of using AMP more:) ). More on point, I wanted to clarify something about your first point, that of dividing the range delimited by an array_view: do you find the array_view::section() function too much of a bother? It does technically create new array_views (they should be fairly lightweight) and it appears that it covers your use case.

    The second point is interesting and will be taken into account, although my personal 2c on the matter is that there is an even better solution for the whole TDR situation, once hardware and low-level interfaces to said hardware take another bold step forward:) Cheers!

    Sunday, June 22, 2014 10:25 AM
  • >> do you find the array_view::section() function too much of a bother?

    Actually, I forgot about those.  I avoided using them only because of the extra complication of also working with uchars.  It made the coding more difficult and hard to maintain.  Under normal (ie, floating point) circumstances, they would be fine, I think.  But I almost always have to work with uchar.

    Monday, June 23, 2014 6:45 PM
  • Hmm, interesting. Do you have a small example of what you're doing (something with foo, bar, baz and all that good stuff), just to illustrate the case / pattern? Perhaps we can work something out - this does not mean we're not looking at the suggestion, but I think you'd appreciate a solution now. Cheers!
    Tuesday, June 24, 2014 9:47 PM