SYCL Resource - In order queue

[homerdin]

Changing SYCL resources to use in order queue property to ensure expected functionality.

[trws]

I was reminded to revisit this in the meeting this morning. @homerdin, I'm good with this conceptually, but doesn't creating them this way create them all with separate contexts? I would think we need the resource implementation to have or take a context (or get one from the first queue perhaps) and use it to create the others to make them compatible right?

[homerdin]

@trws I've updated the sycl resource to use a single context and optionally take a context on construction.

[trws]

Thanks @homerdin, this looks good for the default case. What will it do with a specified context though? If I'm interpreting it right, since the static is only initialized once, I think the list of queues will get initialized with whatever context is used the first time a queue is requested and then all subsequent calls will ignore the context and give one of the queues created at the beginning. Is that right?

[homerdin]

@trws Yeah, the subsequent calls will give a queue from the original context. We can add some dynamic memory if they want to build a resource from a second context. I'm not sure if any application will building multiple contexts. At a minimum I should add some messaging if a second context gets passed in. Let me know and I can add some functionality for working with multiple contexts.

[trws]

I think we probably need to, at least one custom one and the default at a minimum. Otherwise this could get called in some init code, even if it’s never used, and lock into the default-generated camp context without leaving the user a way to fix it.

[homerdin]

@trws I took a pass at adding support for different contexts, let me know what you think.

Currently the logic is to use the context when given. When no context is given, use the previous one or a private one(when the user never creates one).

This would require that if the user is creating multiple resources on different threads with thread private contexts, they would need to be explicit each time and not rely on the previous context passed.

[trws]

That works for me. I just went in and formatted it to match style, and will rebase it shortly.

[trws]

@homerdin, this is rebased and formatted. Would you take a look and maybe poke at it before I merge to make sure something didn't break in the process?

[homerdin]

@trws I pulled down the changed and tested them. Everything looks good.

[trws]

Excellent, thanks @homerdin!