search for: kindly

Turing introduced a new simplified page kind scheme, reducing the number of possible page kinds from 256 to 16. It also is the first NVIDIA GPU in which the highest possible page kind value is not reserved as an "invalid" page kind. To address this, the invalid page kind is made an explicit property of the MMU HAL, and a new table of page kinds is added to the tu102 MMU HAL. One

Hi all, I?m fitting GLM?s and I can?t interprete the coefficients when I run a model with interaction terms. When I run the simpliest model there is no problem: Model1<-glm (Fishes ~ Year + I(Year^2) + Kind.Geographic + Kind.Fishers + Zone.2 + Hours + Fishers + Month, family = poisson(log)) # Fishes, Year, Hours, and Fishers are numeric, Kind.Geographic, Kind.Fishers, Zone.2 and

Starting with example Wichmann-Hill code from Brian Ripley I have been playing with a set of programs for getting the same random sequences from R and Splus. A copy is included below along with a test (which works in Solaris with R and Splus 3.3). The approach is somewhat different from the usual problems on this list as I am trying to get the same results from Splus as I get from R. However,

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

Hello, I am initializing FDR mode and finalizing/flushing the buffers manually. XRay does not log calls from the main thread unless there is a function call after __xray_log_finalize(). This behavior is abnormal since one would expect the trace file to contain all function calls made up to the point when __xray_log_finalize() is called. To demonstrate this behavior, I have taken the test case

Hi, I am parsing a C++ file using cindex.py and want to get the template parameters to a specific node. However, the tree seems to be different depending on if the template parameter is a struct/class or a simple type such as int or float. In the first case the template type is appended as a child to the VAR_DECL node (the TYPE_REF node seen in the example below), but this is not the case with

Justin, thanks for the reply. I would like to point out that value_kind is actually not really stored in the raw profile data (nor do we intend to do so), other than the minimal information about per value kind NumOfSites info in per-function profile header. Basically the data is organized per value kind instead of stored intermixed. That is about it. More replies below. On Mon, Jun 29, 2015

My suggestion: 1. Keep the value kind enum, but remove the reserved kinds 2. In compiler-rt code, assert the kind to be icalltarget and remove the loop 3. Keep the indexed format (as is now) 4. Add assertion in profile use that icalltarget is the only expected kind. Justin, does this sound reasonable? David On Jul 2, 2015 1:10 PM, "Betul Buyukkurt" <betulb at codeaurora.org>

> Xinliang David Li <davidxl at google.com> writes: >> Justin, thanks for the reply. >> I would like to point out that value_kind is actually not really stored in the raw profile data (nor do we intend to do so), other than the minimal information about per value kind NumOfSites info in per-function profile header. Basically the data is organized per value kind instead of

Justin, do you have more concerns on keeping value_kind? If there is still disagreement, can we agree to move on with it for now ? After the initial version of the patches checked in, we can do more serious testings with large apps and revisit this if there are problems discovered. thanks, David On Mon, Jun 15, 2015 at 10:47 PM, Xinliang David Li <davidxl at google.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 by the target display hardware. Signed-off-by: James Jones <jajones at nvidia.com> ---

On 12/11/19 1:13 PM, Ilia Mirkin wrote: > 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

Xinliang David Li <davidxl at google.com> writes: > On Mon, Jun 15, 2015 at 5:35 PM, Justin Bogner <mail at justinbogner.com> wrote: >> "Betul Buyukkurt" <betulb at codeaurora.org> writes: >>>> - We don't need to store the value profiling kind in the data at all. >>>> The frontend knows which invocations of the intrinsic are for

Dear all, In our compiler we use a modified version LLVM Polly, which is very sensitive to proper code generation. Among the number of limitations, the loop region (enclosed by phi node on induction variable and branch) is required to be free of additional memory-dependent branches. In other words, there must be no conditional "br" instructions below phi nodes. The problem we are facing

I find the documention for RNGversion in R-devel is a bit misleading, and suggest adding a sentence to make it clear that the meaning of "default" is not set to its meaning in the earlier R version: `RNGversion' can be used to set the random generators as they were in an earlier R{} version (for reproducibility). RNGversion does not set the meaning of

Hi Daniel, thanks for the quick reply we did try to override SMBIOS host_uuid_source = "machine-id" and it didn't work even that nodes have different [root@modi01 kubevirt]# ./cluster-up/ssh.sh kind-1.17.0-worker root@kind-1:/# cat /etc/machine-id [root@modi01 kubevirt]# ./cluster-up/ssh.sh kind-1.17.0-control-plane root@kind-1:/# cat /etc/machine-id

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available here: https://gitlab.freedesktop.org/cubanismo/mesa/tree/nouveau_work But those need a bit of cleanup before they're ready to submit. I've tested this on Tesla, Kepler, Pascal,

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev gitlab merge request 3724: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using

This series modifies the NV5x+ nouveau display backends to advertise appropriate format modifiers on their display planes in atomic mode setting blobs. Corresponding modifications to Mesa/userspace are available on the Mesa-dev gitlab merge request 3724: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3724 I've tested this on Tesla, Kepler, Pascal, and Turing-class hardware using

Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes, in particular in the context in which this code is being used. So, replace the following form: sizeof(*kind) + sizeof(*kind->data) * mmu->kind_nr; with: struct_size(kind, data, mmu->kind_nr) This code was detected with the help of Coccinelle. Signed-off-by: Gustavo A.