Substitution/Replacements problem

S. Bharadwaj Yadavalli bharadwaj.yadavalli at oracle.com
Tue Mar 4 07:23:44 PST 2014


On 03/04/2014 05:01 AM, Doug Simon wrote:
> On Mar 4, 2014, at 1:47 AM, Christian Thalinger <christian.thalinger at oracle.com> wrote:
>
>> On Mar 3, 2014, at 3:25 PM, Eric Caspole <eric.caspole at amd.com> wrote:
<...>
>>> Up til now, we have been using the replacements/inline mechanism for example AtomicInteger that end up as fence/load/fence type ops, and other uses, that get inlined into the kernel body and that is working well so far.
>>>
>>> I have a suitable PTX card in my box so I might be the only one in the group that might see this problem. The existing HSAIL KernelTester tests in the public repo do not get this problem since the harness sends an ordinary method to get HSAIL-compiled and they are not called "lambda$..."
>>>
>>> I think I see that the strategy for offloading for PTX so far is doing a "replacement" of a CPU method with a GPU kernel. But we also want to have some replacements/inlining inside the kernel.
> This integration of GPU offloading into the normal compiler pipeline is a hack that should be removed. I put it in only so that Bharadwaj could easily test PTX offloading without having to do the Stream API interposition. The reason that it’s a hack is that it exactly ignores the policy problem of what to offload and to which available GPU. Bharadwaj, can you move to the Sumatra way of offloading soon? Once you’ve done this, I’ll remove this hack.

I'll work on making the needed changes.

Bharadwaj



More information about the sumatra-dev mailing list