similar to: [PATCH v2] nouveau: fix the start/end range for migration

The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- This is for Ben Skegg's nouveau tree. I have been working with Karol Herbst on the

The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> --- I thought I sent this out earlier but I don't see any record of that so I'm resending

On 8/31/20 4:51 AM, Jason Gunthorpe wrote: > On Thu, Aug 27, 2020 at 02:37:44PM -0700, Ralph Campbell wrote: >> The user level OpenCL code shouldn't have to align start and end >> addresses to a page boundary. That is better handled in the nouveau >> driver. The npages field is also redundant since it can be computed >> from the start and end addresses. >>

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell

On Thu, Aug 27, 2020 at 02:37:44PM -0700, Ralph Campbell wrote: > The user level OpenCL code shouldn't have to align start and end > addresses to a page boundary. That is better handled in the nouveau > driver. The npages field is also redundant since it can be computed > from the start and end addresses. > > Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> >

On Mon, Aug 31, 2020 at 10:21:41AM -0700, Ralph Campbell wrote: > > On 8/31/20 4:51 AM, Jason Gunthorpe wrote: > > On Thu, Aug 27, 2020 at 02:37:44PM -0700, Ralph Campbell wrote: > > > The user level OpenCL code shouldn't have to align start and end > > > addresses to a page boundary. That is better handled in the nouveau > > > driver. The npages field

Originally patch 4 was targeted for Jason's rdma tree since other HMM related changes were queued there. Now that those have been merged, these patches just contain changes to nouveau so they could go through any tree. I guess Ben Skeggs' tree would be appropriate. Changes since v2: Added patches 1-3 to fix some minor issues. Eliminated nouveau_find_svmm() since it is easily found.

When memory is migrated to the GPU it is likely to be accessed by GPU code soon afterwards. Instead of waiting for a GPU fault, map the migrated memory into the GPU page tables with the same access permissions as the source CPU page table entries. This preserves copy on write semantics. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com> Cc: Christoph Hellwig <hch at lst.de> Cc:

Hi, Chris Lattner wrote: > All the non-vastart calls can be anywhere. va_end in particular codegens > to a noop on all targets llvm currently supports, fwiw. > Things go well, except for the following (pathological?) C program: int va_double_sum(int count,...){ int i,sum=0; va_list ap; va_start(ap,count); for(i=0;i<count;i++){ sum+=va_arg(ap,int); } va_end(ap);

Full_Name: Kenji Rikitake Version: 2.3.1 OS: FreeBSD 4.11-RELEASE-p18 Submission from: (NULL) (220.157.163.221) After doing ./configure --disable-mbcs (as default in FreeBSD 4.x) and make the compilation stops at src/main/printutils.c as: printutils.c: In function `Rvprintf': printutils.c:582: `va_start' used in function with fixed args printutils.c:591: syntax error before `}' the

On Tue, 3 Oct 2006, Bram Adams wrote: >> You'd have to change it to something like: >> void foo(int X, ...) { >> P = va_start(); >> bar(X, P); >> } >> >> void bar(int X, valist P) { >> use(P); >> } > > Can the other va_...-intrinsics be used in bar as were the "P = > va_start" in bar? The va_start probably is

Hi, So the Variable Argument Handling Intrinsics section of the LangRef (http://llvm.org/docs/LangRef.html#variable-argument-handling-intrinsics) lists an example that segfaults. Try the following on x86_64: -- 8< -- define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) ; Read a

Hi, Op 3-okt-06, om 20:48 heeft Chris Lattner het volgende geschreven: > You'd have to change it to something like: > > void foo(int X, ...) { > P = va_start(); > bar(X, P); > } > > void bar(int X, valist P) { > use(P); > } Can the other va_...-intrinsics be used in bar as were the "P = va_start" in bar? The va_start probably is unnecessary

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ] When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ] When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>

From: Ralph Campbell <rcampbell at nvidia.com> [ Upstream commit 822cab6150d3002952407a8297ff5a0d32bb7b54 ] When migrating system memory to GPU memory, check that SVM has been enabled. Even though most errors can be ignored since migration is a performance optimization, return an error because this is a violation of the API. Signed-off-by: Ralph Campbell <rcampbell at nvidia.com>

Hi, I am using llc (llvm 2.9) to generate the MIPS assembly, but failed when compile any codes with va_start()/va_end()/va_arg(). Here is the minimal step to reproduce the failure: llvm-gcc-4.2 -emit-llvm hello.c -c -o hello.bc llc -march=mips hello.bc -o hello.s llc show this erroe message: LLVM ERROR: Cannot select: 0xa1873a0: ch = vaend 0xa187290:1, 0xa185ae0, 0xa187318 [ID=38] 0xa185ae0:

target datalayout = "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32" target triple = "i686-pc-windows-msvc" declare void @llvm.va_start(i8**) declare void @llvm.va_end(i8**) define i64 @foo(...) { %va = alloca i8*, i32 16 ; 4 words should be enough? call void @llvm.va_start(i8** %va) %x = va_arg i8** %va, i64 call void @llvm.va_end(i8** %va) ret i64 %x }