search for: modifies

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

On 7/23/20 9:06 PM, Ben Skeggs wrote: > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: >> >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() >> family of modifiers to handle broken userspace >> Xorg modesetting and Mesa drivers. Existing Mesa >> drivers are still aware of only these older >> format modifiers which do not

I've been unable to bootstrap llvm-gcc-4.0 or -4.2 for x86_64 for some weeks now. The current problem is this: [x86_64-mod-dbg]: ./xgcc -B./ -B/install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -isystem /install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown-linux-gnu/include -isystem

On Wed, 29 Jul 2020 at 12:48, Dave Airlie <airlied at gmail.com> wrote: > > On Tue, 28 Jul 2020 at 04:51, James Jones <jajones at nvidia.com> wrote: > > > > On 7/23/20 9:06 PM, Ben Skeggs wrote: > > > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: > > >> > > >> Accept the

I made my first attempt to build on an x86_64-unknown-linux-gnu system. Is this supposed to work? I get libtools errors (below). The problem seems to be that it finds a 32-bit libltdl rather than the 64-bit libltdl. /home/dag> ls /usr/lib/libltdl.so.3.1.0 /usr/lib/libltdl.so.3.1.0 /home/dag> ls /usr/lib64/libltdl.so.3.1.0 /usr/lib64/libltdl.so.3.1.0 Is this a known problem?

Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() family of modifiers to handle broken userspace Xorg modesetting and Mesa drivers. Existing Mesa drivers are still aware of only these older format modifiers which do not differentiate between different variations of the block linear layout. When the format modifier support flag was flipped in the nouveau kernel driver, the X.org modesetting driver

On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: > > Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > family of modifiers to handle broken userspace > Xorg modesetting and Mesa drivers. Existing Mesa > drivers are still aware of only these older > format modifiers which do not differentiate > between different variations of the block linear >

I am trying to install Rcmdr on my ubuntu machine, but keep getting the following error messages: ERROR: failed to lock directory ?/home/thedoctor/R/i486-pc-linux-gnu-library/2.10? for modifying Try removing ?/home/thedoctor/R/i486-pc-linux-gnu-library/2.10/00LOCK? ERROR: failed to lock directory ?/home/thedoctor/R/i486-pc-linux-gnu-library/2.10? for modifying Try removing

On Oct 8, 2007, at 12:50 PM, David Greene wrote: > I've been unable to bootstrap llvm-gcc-4.0 or -4.2 for x86_64 > for some weeks now. The current problem is this: > > [x86_64-mod-dbg]: ./xgcc -B./ > -B/install.modified.debug/x86_64-unknown-linux-gnu/x86_64-unknown- > linux-gnu/bin/ > -isystem /install.modified.debug/x86_64-unknown-linux-gnu/x86_64- >

On Thu, Jul 30, 2020 at 10:26:17AM -0700, James Jones wrote: > Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > family of modifiers to handle broken userspace > Xorg modesetting and Mesa drivers. Existing Mesa > drivers are still aware of only these older > format modifiers which do not differentiate > between different variations of the block linear > layout. When the format

On Tue, 28 Jul 2020 at 04:51, James Jones <jajones at nvidia.com> wrote: > > On 7/23/20 9:06 PM, Ben Skeggs wrote: > > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at nvidia.com> wrote: > >> > >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() > >> family of modifiers to handle broken userspace > >> Xorg modesetting and Mesa drivers.

On Wed, Jul 29, 2020 at 01:40:13PM +1000, Ben Skeggs wrote: > On Wed, 29 Jul 2020 at 12:48, Dave Airlie <airlied at gmail.com> wrote: > > > > On Tue, 28 Jul 2020 at 04:51, James Jones <jajones at nvidia.com> wrote: > > > > > > On 7/23/20 9:06 PM, Ben Skeggs wrote: > > > > On Sat, 18 Jul 2020 at 13:34, James Jones <jajones at

Dear list, I wish to modify programmatically only a few factor levels, according to a named list. I came up with this function, modify.levels <- function(f, modify=list()){ ## levels that will not be changed names.old.levels <- setdiff(levels(f), unlist(modify)) ## as a named list old.levels <- as.pairlist(names.old.levels) names(old.levels) <- names.old.levels ## union

On 1/21/2013 2:01 AM, Óscar Fuentes wrote: > Ashok Nalkund <ashoknn at qti.qualcomm.com> writes: > >> I was using the find_package(LLVM llvm/share/llvm/cmake) and >> llvm_map_components_to_libraries(REQ_LLVM_LIBRARIES jit native) to get >> the libraries to link against. This works well for the libLLVM* >> libraries, but how do I implement similar find stuff for

On Mon, 8 Oct 2007, Evan Cheng wrote: >> [x86_64-mod-dbg]: /tmp/ccxekXCc.s: Assembler messages: >> [x86_64-mod-dbg]: /tmp/ccxekXCc.s:36: Error: `(%esi,%edi)' is not a >> valid 64 >> bit base/index expression > > Looks like llvm is generating invalid x86-64 assembly. Can you add a - > emit-llvm to the xgcc line and generate a reproducible test case? > Please

On 7/17/20 12:47 PM, Daniel Vetter wrote: > On Fri, Jul 17, 2020 at 11:57:57AM -0700, James Jones wrote: >> Accept the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK() >> family of modifiers to handle broken userspace >> Xorg modesetting and Mesa drivers. >> >> Tested with Xorg 1.20 modesetting driver, >> weston at c46c70dac84a4b3030cd05b380f9f410536690fc, >> gnome

Sorry for this long message. The two first questions asks for general coding standard when creating packages, the third one asks if the .R files are concatenated in lexical order or not, the fourth question is a "how-to" question. All questions are related. If there is a reference where I can read about this please tell me, because then I could repost a more restricted set of questions.

On Wed, Dec 11, 2019 at 4:04 PM James Jones <jajones at nvidia.com> wrote: > > Allow setting the block layout of a nouveau FB > object using DRM format modifiers. When > specified, the format modifier block layout and > kind overrides the GEM buffer's implicit layout > and kind. The specified format modifier is > validated against he list of modifiers supported

...;between the caller and the callee" part. The way I see this, the responsibility for the copying should be with either the caller or the callee, not somewhere in between. In particular, I think byval could either mean: a) The callee is not allowed to modify the argument. If the original code modifies the argument, the callee should make a copy and modify that instead. b) The caller will always pass in a copy of the object, which the callee is free to modify and will be thrown away afterwards. In both cases, it seems that byval argument must always be a valid pointer. From the code, I suspe...