jhuber6 wrote:
Fixed the managed stuff in https://github.com/llvm/llvm-project/pull/123437,
should be good enough for the foreseeable future.
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http
jhuber6 wrote:
> > > For now, it's probably easier just to put some indirection in this and
> > > pass a struct to the first argument.
> >
> >
> > It would be even easier to not make the move. Does "addr" have different
> > meanings in each context where an offload_entry is used? Is this goin
jhuber6 wrote:
> > For now, it's probably easier just to put some indirection in this and pass
> > a struct to the first argument.
>
> It would be even easier to not make the move. Does "addr" have different
> meanings in each context where an offload_entry is used? Is this going to
> confuse
b-sumner wrote:
> For now, it's probably easier just to put some indirection in this and pass a
> struct to the first argument.
It would be even easier to not make the move. Does "addr" have different
meanings in each context where an offload_entry is used? Is this going to
confuse the debu
jhuber6 wrote:
> > I'd like to avoid modifying this struct to avoid breaking ABI with OpenMP.
> > Perhaps I should make `addr` a pointer to a struct and just GEP the two
> > values.
>
> Are we trying to jam a square HIP peg into a round OpenMP hole, or are we
> truly wanting to move to a lang
b-sumner wrote:
> I'd like to avoid modifying this struct to avoid breaking ABI with OpenMP.
> Perhaps I should make `addr` a pointer to a struct and just GEP the two
> values.
Are we trying to jam a square HIP peg into a round OpenMP hole, or are we truly
wanting to move to a language neutra
jhuber6 wrote:
@yxsamliu Here's the general problem, the `__hipRegisterManagedVar` call takes
the following arguments.
```c
__hipRegisterManagedVar(void ** handle, char *ManagedVarPtr, char *VarPtr,
const char *VarName, size_t Size, unsigned Alignment)
```
But the struct that we store this in
jhuber6 wrote:
I somehow totally forgot that I implemented surfaces and textures, it was
`managed` that I was having problems with.
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.
https://github.com/jhuber6 updated
https://github.com/llvm/llvm-project/pull/123359
>From ce890d0f8f34dc1a32edf41571f0a432e4c03586 Mon Sep 17 00:00:00 2001
From: Joseph Huber
Date: Fri, 17 Jan 2025 09:35:34 -0600
Subject: [PATCH] [HIP] Move HIP to the new driver by default
Summary:
This patch
b-sumner wrote:
> If it's a blocker I can try to find a way to work around it. I don't think I
> found a single runtime test for it, so I figured it's hardly used.
https://github.com/ROCm/hip-tests/tree/amd-staging/catch/unit/surface
https://github.com/llvm/llvm-project/pull/123359
_
jhuber6 wrote:
> > Surfaces and textures are being phased out of CUDA as far as I can tell, so
> > I wasn't sure how relevant it was (since we can use
> > `--no-offload-new-driver` as a workaround for now). CUDA clang doesn't even
> > handle surfaces, and as far as I can tell the old `cudaRegi
b-sumner wrote:
> Surfaces and textures are being phased out of CUDA as far as I can tell, so I
> wasn't sure how relevant it was (since we can use `--no-offload-new-driver`
> as a workaround for now). CUDA clang doesn't even handle surfaces, and as far
> as I can tell the old `cudaRegisterSu
jhuber6 wrote:
> Breaking any existing HIP feature is a no-go in my opinion. Textures and
> surfaces are important to some developers.
Surfaces and textures are being phased out of CUDA as far as I can tell, so I
wasn't sure how relevant it was (since we can use `--no-offload-new-driver` as
a
arsenm wrote:
I don't follow the connection to textures
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
b-sumner wrote:
Breaking any existing HIP feature is a no-go in my opinion. Textures and
surfaces are important to some developers.
https://github.com/llvm/llvm-project/pull/123359
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists
llvmbot wrote:
@llvm/pr-subscribers-clang-driver
Author: Joseph Huber (jhuber6)
Changes
Summary:
This patch matches CUDA, moving the HIP compilation jobs to the new
driver by default. The old behavior will return with
`--no-offload-new-driver`. The main difference is that objects compiled
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: Joseph Huber (jhuber6)
Changes
Summary:
This patch matches CUDA, moving the HIP compilation jobs to the new
driver by default. The old behavior will return with
`--no-offload-new-driver`. The main difference is that objects compiled
with th
https://github.com/jhuber6 created
https://github.com/llvm/llvm-project/pull/123359
Summary:
This patch matches CUDA, moving the HIP compilation jobs to the new
driver by default. The old behavior will return with
`--no-offload-new-driver`. The main difference is that objects compiled
with the o
18 matches
Mail list logo
