search for: usermem

Memory was always allocated for 4096 channels. Change this to allocate what we actually need according to the number of channels we use. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c

Memory was always allocated for 4096 channels. Change this to allocate what we actually need according to the number of channels we use. Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> --- drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c

On Mon, Feb 10, 2014 at 02:57:01PM +0900, Alexandre Courbot wrote: > Memory was always allocated for 4096 channels. Change this to allocate > what we actually need according to the number of channels we use. > > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/core/engine/fifo/nve0.c | 4 ++-- > 1 file changed, 2 insertions(+),

From: Thierry Reding <treding at nvidia.com> Hi Ben, these are a couple of patches that are in preparation for adding GV11B support. The fundamental issue that these are trying to solve is that the GV11B is the first Tegra incarnation of the GPU where the aperture really matters. All prior generations would accept any of them. For dGPUs we usually allocate memory in VRAM, so the default

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Not 100% sure that this is needed, but BSP/MPEG are in the mask. drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c b/drivers/gpu/drm/nouveau/core/subdev/mc/nv50.c index 0cb322a..f25fc5f 100644 ---

Hi, I try to use lm to fit a linear model with 600k rows and 70 attributes. But I can't even load the data into the R environment. The error message says the vector memory is used up. Is there anyone having experience with large datasets in R? (I bet) Please advise. thanks, Yun-Fang [[alternative HTML version deleted]]

...>screen_base + pos; > + size_t alloc_size = min(count, PAGE_SIZE); > + ssize_t ret = 0; > + char *tmp; > + > + tmp = kmalloc(alloc_size, GFP_KERNEL); > + if (!tmp) > + return -ENOMEM; > + I looked around and could not find other places where we copy from iomem to mem to usermem in chunks of PAGE_SIZE. > + while (count) { > + size_t c = min(count, alloc_size); > + > + memcpy_fromio(tmp, src, c); > + if (copy_to_user(buf, tmp, c)) { > + ret = -EFAULT; > + break; > + } > + > + src += c; > + buf += c; > + ret += c; > + count...

...evices > drm/nouveau/bar: only ioremap BAR3 if it exists > drm/nouveau/bar/nvc0: support chips without BAR3 > drm/nouveau/mc: support platform devices > drm/nouveau/fb: support platform devices > drm/nouveau/timer: skip calibration on GK20A > drm/nouveau/fifo: allocate usermem as needed > drm/nouveau/fifo: add GK20A support > drm/nouveau/ibus: add GK20A support > drm/nouveau/fb: add GK20A support > drm/nouveau: support GK20A in nouveau_accel_init() > drm/nouveau: support for probing GK20A > > drivers/gpu/drm/nouveau/Makefile...

Hello, Since FreeBSD 9.1 I have strange problems with the distribution. Some servers are rebooting without any kernel panic, instanly. First i thought it's a problem with my KVM system, but one of my FreeBSD under a Dell R210 have the same problem. The servers concerned are now: - Monitoring server - LDAP test server - Some other servers, randomly (not in production). First i thought it's

...ouveau/bar: support platform devices drm/nouveau/bar: only ioremap BAR3 if it exists drm/nouveau/bar/nvc0: support chips without BAR3 drm/nouveau/mc: support platform devices drm/nouveau/fb: support platform devices drm/nouveau/timer: skip calibration on GK20A drm/nouveau/fifo: allocate usermem as needed drm/nouveau/fifo: add GK20A support drm/nouveau/ibus: add GK20A support drm/nouveau/fb: add GK20A support drm/nouveau: support GK20A in nouveau_accel_init() drm/nouveau: support for probing GK20A drivers/gpu/drm/nouveau/Makefile | 4 + drivers/gpu/drm/nouve...

...PMAP1changedcpu: 1 debug.PMAP1changed: 1622 debug.PMAP1unchanged: 162299 debug.acpi.do_powerstate: 1 debug.acpi.acpi_ca_version: 0x20041119 debug.acpi.semaphore_debug: 0 hw.machine: i386 hw.model: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ hw.ncpu: 2 hw.byteorder: 1234 hw.physmem: 2138202112 hw.usermem: 2118488064 hw.pagesize: 4096 hw.floatingpoint: 1 hw.machine_arch: i386 hw.realmem: 2147155968 hw.aac.iosize_max: 65536 hw.amr.force_sg32: 0 hw.an.an_dump: off hw.an.an_cache_mode: dbm hw.an.an_cache_mcastonly: 0 hw.an.an_cache_iponly: 1 hw.ata.ata_dma: 1 hw.ata.atapi_dma: 1 hw.ata.wc: 1 hw.cardbus...

[Moved from -current to -stable] ???????? 21 ???????? 2006 16:23, Matthew Dillon ?? ????????: > ? ? You might be doing just writes to the mmap()'d memory, but the system > ? ? doesn't know that. Actually, it does. The program tells it, that I don't care to read, what's currently there, by specifying the PROT_READ flag only. > ? ? The moment you touch any mmap()'d

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use