Substitution/Replacements problem
Eric Caspole
eric.caspole at amd.com
Tue Mar 4 07:28:24 PST 2014
That will be great, I was thinking yesterday we could then have at least
a couple simple offload tests in common for the two GPUs.
On 03/04/2014 10:23 AM, S. Bharadwaj Yadavalli wrote:
>
> 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 graal-dev
mailing list