search for: overallocation

...ports pre-G80 GPUs, and again, not compatible with > nouveau. > > DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an > fbdev interface for legacy applications. The fbdev emulation acts as > sort of a regular DRM client and exposes the FBDEV API. > > The overallocation logic was added to this emulation layer in commit > 5f15257689bfa, which is included in v4.12 and later kernels. > > Hope this helps, > > -ilia > > On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos > <michael at michaelkloos.com> wrote: >> Well...it's been a...

...the mmap to fail. I no longer believe that it is a driver issue, though, because I just tried it again on a dell laptop with Intel HD Graphics 4400 to the same failure. >> >> On Jul 5, 2020 12:35, Ilia Mirkin <imirkin at alum.mit.edu> wrote: >> >> 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": >>> >>>...

...ail_quote">On Jul 5, 2020 12:35, Ilia Mirkin <imirkin@alum.mit.edu> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Are you setting the overallocation to 200? <br> <br> On Sun, Jul 5, 2020 at 3:41 AM Michael T. Kloos <br> <michael@michaelkloos.com> wrote: <br> > <br> > Does NOUVEAU support mmaping a double-sized Framebuffer? <br> > When attempting to run, where fd refers to "/dev/fb0":...

...e need to know the size // * For that, we need to know how many dynamic relocs we will have. ``` But I think you can resize a memory mapping (e.g. ftruncate) to add data at the end. Or conservatively overallocate and then truncate at the end (pages we don't touch won't be allocated, so the overallocation shouldn't cost too much) -- Sean Silva > > On Tue, Feb 28, 2017 at 11:15 PM, Sean Silva <chisophugis at gmail.com> > wrote: > >> >> >> On Tue, Feb 28, 2017 at 12:10 PM, Rui Ueyama <ruiu at google.com> wrote: >> >>> I don't think ge...

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

...nything newer. Most likely it supports pre-G80 GPUs, and again, not compatible with nouveau. DRM-based drivers use the DRM <-> FBDEV emulation layer to provide an fbdev interface for legacy applications. The fbdev emulation acts as sort of a regular DRM client and exposes the FBDEV API. The overallocation logic was added to this emulation layer in commit 5f15257689bfa, which is included in v4.12 and later kernels. Hope this helps, -ilia On Sun, Jul 5, 2020 at 7:02 PM Michael T. Kloos <michael at michaelkloos.com> wrote: > > Well...it's been a bit of a mixed bag. Setting > dr...

- 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, MA...

...e, but it caused the mmap to fail. I no longer believe that it is a driver issue, though, because I just tried it again on a dell laptop with Intel HD Graphics 4400 to the same failure. > > On Jul 5, 2020 12:35, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > > 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, scr...

Jason Nader (1): Add missing `-help` function Keith Packard (5): Make output with unknown width terminal the same as old code Free string list returned 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

>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

I have found what seems to be a bug in warning(), but perhaps I'm being really boneheaded (it's happened before). Essentially, warning() seems to segfault if its argument is greater than 8191 characters (8192 is defined as BUFSIZE in errors.c, so a quick workaround would be to boost this ...) The bug was initially provoked by trying to concatenate two long tables -- the warning message

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