search for: overallocating

Oops, the FBIOPAN_DISPLAY ioctl error was a stupid mistake on mistake on my part.? Thanks for the info on where the validation code was.? Comparing against that made it easy to find the mistake.? It's working now, well...where I have been able to get over-allocation working!? Thanks for the help.? If I can't get the over-allocation to work on my other systems, I'll take it up in

Well...it's been a bit of a mixed bag.? Setting drm_kms_helper.drm_fbdev_overalloc=200 set the vinfo.yres_virtual to 2160 as opposed to 1080 (My monitor vertical resolution)? This fixed the mmap() problem.? However, it only worked on my main workstation.? My laptop running Intel graphics wasn't affected by the change in kernel cmdline.? My workstation is a custom build from a few

<div dir='auto'>I am not familiar with that setting, but I have really struggled to find documentation on dealing with the framebuffer. Referring to this guide, "http://betteros.org/tut/graphics1.php#doublebuffer", I attempted to set the mmap allocation size to double, but it caused the mmap to fail. I no longer believe that it is a driver issue, though, because I just

On Tue, Feb 28, 2017 at 11:39 PM, Rui Ueyama <ruiu at google.com> wrote: > I also did a quick profiling a few months ago and noticed just like you > that scanRelocations consumes a fairly large percentage of overall > execution time. That caught my attention because at the time I was looking > for a place that I can parallelize. > > scanRelocations is not parallelizable

Does NOUVEAU support mmaping a double-sized Framebuffer? When attempting to run, where fd refers to "/dev/fb0": mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); I get back an invalid argument error. This doesn't happen if I only request a single screensize. Is this a limitation of the driver? -------------- next part -------------- An HTML attachment was

Check fb_pan_display in drivers/video/fbdev/core/fbmem.c for the argument validation of the FBIOPAN_DISPLAY ioctl. CONFIG_FB_NVIDIA is a dedicated fbdev driver, not compatible with nouveau (it takes over the relevant PCI device). It also won't support your Pascal GPU, I believe -- I think it MIGHT support the Tesla generation (i.e. G80..GT21x) but definitely not anything newer. Most likely it

- Depth and stencil buffers are supposed to be large enough in general. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bo.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index e342a41..9fc4bd6 100644 ---

Hello, First of all, I already contacted Martin Devera, the developer of HTB, and he told me to search for help on this mailinglist, thus I am describing my problems here now... I am kind of seriously annoyed by QoS as I have been trying for over 3 years to get it working properly - first I did not understand how it works, then it seemed not to work, then it was working perfectly for half a

Dynamically resizing the framebuffer on nv04 was like playing Russian roulette (and it often happened gratuitously) because it seems unable to scan out from buffers above 16MB. This patch splits the mappable VRAM into two chunks when that's the case, and makes the higher one to be used as well when applicable. Signed-off-by: Francisco Jerez <currojerez at riseup.net> ---

Are you setting the overallocation to 200? On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos <michael at michaelkloos.com> wrote: > > Does NOUVEAU support mmaping a double-sized Framebuffer? > When attempting to run, where fd refers to "/dev/fb0": > > mmap(ptr, screensize * 2, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); > > I get back an invalid argument error.

Try booting with drm_kms_helper.drm_fbdev_overalloc=200 and see if it works with that. (There's also CONFIG_DRM_FBDEV_OVERALLOC which sets the default.) Cheers, -ilia On Sun, Jul 5, 2020 at 3:41 PM <michael at michaelkloos.com> wrote: > > I am not familiar with that setting, but I have really struggled to find documentation on dealing with the framebuffer. Referring to this

...from XmbTextPropertyToTextList Correct icon buffer width computation for truecolor terminals Check return value from ioctl(TIOCGWINSZ) xprop 1.2.5 Pierre-Loup A. Griffais (5): Don't display icons if they would line-wrap. Break down memory allocation logic and fix overallocating for UTF8. Fix aspect ratio for icon display by using two characters per icon pixel. Support true color output for icons if the terminal advertises it. Fix formatting of back-to-back not shown icons. git tag: xprop-1.2.5 https://xorg.freedesktop.org/archive/individual/app/xprop-1...

>Yes, if you are creating larger files. By default e2fsck assumes the average >file size is 8kB and allocates a corresponding number of inodes there. If, >for example, you are storing lots of larger files there (digital photos, MP3s, >etc) that are in the MB range you can use "-t largefile" or "-t largefile4" >to specify an average file size of 1MB or 4MB

...provoke.bug <- function(r=7500,c=c) { y1 <- matrix(runif(r*c),ncol=c) row.names(y1) <- 1:r y2 <- matrix(runif(r*c),ncol=c) row.names(y2) <- 1:r # problem triggered by data.frame() invisible(data.frame(rbind(y1,y2))) } ## crashes between 1600 and 1700 rows, 1 column ## (overallocating buffer in duplicate rows warning?) provoke.bug2 <- function(n=1600) { str <- as.character(1:n) dup <- duplicated(c(str,str)) trywarn <- paste("duplicates:",paste(which(dup),collapse=",")) cat("Length of warning message:",nchar(trywarn),"\n&quo...

On Tue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: > I don't think getVA is particularly expensive, and if it is not expensive > I wouldn't cache its result. Did you experiment to cache getVA results? I > think you can do that fairly easily by adding a std::atomic_uint64_t to > SymbolBody and use it as a cache for getVA. > You're right,

Hello, I am trying to recursively append some data from multiple files into a common object For this, I am using in a loop NewObject <- rbind(NewObject,tempObject) For the first loop, obviously there is no NewObject ... so I wanted to do NewObject <- tempObject[0,] Now when it loops again I want to put the statement do "NewObject <- tempObject[0,]" inside a if statement

- In the current situation the padding that is added is dangerous to write to, userspace could potentially overwrite parts of another bo. - Depth and stencil buffers are supposed to be large enough in general so the waste of memory should be acceptable. - Alternatives are hiding the padding from users or splitting vram into 2 zones. Signed-off-by: Maarten Maathuis <madman2003 at gmail.com>

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

I've posted two patches on Phabricator to add support for VScale in LLVM. A brief recap on `vscale`: The scalable vector type in LLVM IR is defined as `<vscale x n x m>`, to create types such as `<vscale x 16 x i8>` for a scalable vector with at least 16 bytes. In the definition of the scalable type, `vscale` is specified as a positive constant of type integer that will only be

On Tuesday, October 1, 2019, Jacob Lifshay <programmerjake at gmail.com> wrote: > On Mon, Sep 30, 2019 at 2:30 AM Sander De Smalen via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > > I've posted two patches on Phabricator to add support for VScale in LLVM. Excellent! > > > > A brief recap on `vscale`: > > The scalable vector type in