search for: gpus

...ere: -Is the level of backwards compatibility described here sufficient? Technically I can make the user space drivers support the old modifiers too, but that would mean the layout they specify would morph based on the GPU they're being used on, and sharing buffers between two different NV GPUs, which would appear to be possible, would result in corruption on one side or the other. -I used "magic" numbers for all the bit shifting. Would it be better to use __fourcc_XXX constants like the broadcom modifiers do? I wasn't sure which style was preferred. The nouveau code...

...o value for the "kind" field, which is > implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK > macro, must be special cased in drivers and > assumed to map to the pre-Turing generic kind of > 0xfe, since a kind of "zero" is reserved for > linear buffer layouts on all GPUs. > > Second, it is assumed backwards compatibility > is only needed when running on Tegra GPUs, and > specifically Tegra GPUs prior to Xavier. This > is based on two assertions: > > -Tegra GPUs prior to Xavier used a slightly > different raw bit layout than desktop GPUs,...

...is > >> implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK > >> macro, must be special cased in drivers and > >> assumed to map to the pre-Turing generic kind of > >> 0xfe, since a kind of "zero" is reserved for > >> linear buffer layouts on all GPUs. > >> > >> Second, it is assumed backwards compatibility > >> is only needed when running on Tegra GPUs, and > >> specifically Tegra GPUs prior to Xavier. This > >> is based on two assertions: > >> > >> -Tegra GPUs prior to Xavier used...

...o quirks. First, the zero value for the "kind" field, which is implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK macro, must be special cased in drivers and assumed to map to the pre-Turing generic kind of 0xfe, since a kind of "zero" is reserved for linear buffer layouts on all GPUs. Second, it is assumed backwards compatibility is only needed when running on Tegra GPUs, and specifically Tegra GPUs prior to Xavier. This is based on two assertions: -Tegra GPUs prior to Xavier used a slightly different raw bit layout than desktop GPUs, making it impossible to directly share...

...o quirks. First, the zero value for the "kind" field, which is implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK macro, must be special cased in drivers and assumed to map to the pre-Turing generic kind of 0xfe, since a kind of "zero" is reserved for linear buffer layouts on all GPUs. Second, it is assumed backwards compatibility is only needed when running on Tegra GPUs, and specifically Tegra GPUs prior to Xavier. This is based on two assertions: -Tegra GPUs prior to Xavier used a slightly different raw bit layout than desktop GPUs, making it impossible to directly share...

...o quirks. First, the zero value for the "kind" field, which is implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK macro, must be special cased in drivers and assumed to map to the pre-Turing generic kind of 0xfe, since a kind of "zero" is reserved for linear buffer layouts on all GPUs. Second, it is assumed backwards compatibility is only needed when running on Tegra GPUs, and specifically Tegra GPUs prior to Xavier. This is based on two assertions: -Tegra GPUs prior to Xavier used a slightly different raw bit layout than desktop GPUs, making it impossible to directly share...

Got a HBS (y'know, Honkin' Big Server, one o' them technical terms), a Dell 720 with two Tesla GPUs. I updated the o/s, 6.5, and I cannot get the GPUs recognized. As a last resort, I d/l NVidia's proprietary driver/installer, 325, and it builds fine... I've yum removed the kmod-nvidia I had on the system, nouveau is blacklisted, and when I reboot, lsmod shows me nvidia loaded, which modin...

...t;kind" field, which is >> implied by the DRM_FORMAT_MOD_NVIDIA_16BX2_BLOCK >> macro, must be special cased in drivers and >> assumed to map to the pre-Turing generic kind of >> 0xfe, since a kind of "zero" is reserved for >> linear buffer layouts on all GPUs. >> >> Second, it is assumed backwards compatibility >> is only needed when running on Tegra GPUs, and >> specifically Tegra GPUs prior to Xavier. This >> is based on two assertions: >> >> -Tegra GPUs prior to Xavier used a slightly >> different ra...

...ally safe to enable MSIs with? > > Sorry for the slow reply, Lucas. > > We enabled MSI interrupts by default relatively recently in the proprietary > driver (version 325.08, released 2013-07-01 according to our public > changelog). This was enabled across the board for all of the GPUs supported > by the latest release series, so NV50 and up. We believe it should be safe to > enable MSI on those GPUs. We never enabled MSI by default on earlier GPUs so > I can't comment there. > > I investigated our internal documentation and source code, and found a couple &g...

Dear All, I just read an announcement saying that Mathematica is launching a version working with Nvidia GPUs. It is claimed that it'd make it ~10-100x faster! http://www.physorg.com/news146247669.html I was wondering if you are aware of any development going into this direction with R? Thanks for sharing your thoughts, Best wishes, Emmanuel

...Thunderbolt controllers on Macs even if their BIOS is > older than 2015, their PCIe ports need to be whitelisted for runtime > PM. For this we need a way to recognize them. > > * Dual GPU MacBook Pros introduced 2011+ can no longer switch external > DisplayPort ports between GPUs. (They're no longer just used for DP > but have become combined DP/Thunderbolt ports.) The driver to switch > the ports, drivers/platform/x86/apple-gmux.c, needs to detect presence > of a Thunderbolt controller and, if found, keep external ports > permanently switched to t...

Dear nouveau@, please forgive me if this is a FAQ or otherwise obvious; it isn't to me from searching the web, the nouveau mailing list archives and various Linux distributions' wiki pages. I'd like to know for which nvidia GPUs a firmware binary blob needs to be loaded to the GPU in order for nouveau to work with it, including binaries from what is often called "linux-firmware". Hopefully more precisely: Are there GPUs supported by nouveau which do not work at all without a binary blob? Are there GPUs which w...

...ght one for the current GPU was declared static, meaning its state was carried over between invocations of the function, and also made the function non-rentrant and thread-unsafe. Since the table is ordered such that newer GPU methods are listed first, the result of this was that initializing newer GPUs after older GPUs would result in no suitable ttm move acceleration operations being found, and ttm would fall back to CPU blits on the older GPUs. This change declares the walking pointer separately from the table and makes it non-static to fix the logic. Signed-off-by: James Jones <jajones at...

...mber 2010 20:11 > As with __local variables, it may be that "kernelness" cannot be > represented in a standard form in LLVM. For example on a CPU a > kernel function may have an additional parameter which is a pointer to > __local memory space, which would not be necessary on GPUs. Then in > fact you would use a standard calling convention on a CPU. > > But for GPUs, I think using the calling convention is appropriate. > If we standardise the calling convention number, this can be the > default behaviour. I don't think we want LLVM-IR coming from an Open...

...t 10:27 AM, Dan Gohman <dan433584 at gmail.com> wrote: > > > More generally, I don’t see a compelling reason for LLVM to add intrinsic support for the version you’re proposing. Your choice can easily be expanded into IR, and does not have the wide hardware support (particularly in GPUs) that the IEEE version does. > > The IEEE version can also be expanded in LLVM IR. And for GPUs, many GPU input languages leave the behavior on NaN unspecified, so it's not obviously the best guide. That’s not generally true. HLSL (DirectX), CUDA, OpenCL, and Metal all have defined sem...

...years of development, various talks on LLVM-HPC and EuroLLVM and other scientific conferences I want to present my PhD research topic to the lists. The main goal for my research was to develop a single-source programming model equal to CUDA or SYCL for accelerators supported by LLVM (e.g., Nvidia GPUs). PACXX uses Clang as front-end for code generation and comes with a runtime library (PACXX-RT) to execute kernels on the available hardware. Currently, PACXX supports Nvidia GPUs through the NVPTX Target and CUDA, CPUs through MCJIT (including whole function vectorization thanks to RV [1]) and has...

> -----Original Message----- > From: Stellard, Thomas > Sent: Monday, May 28, 2012 9:07 AM > To: Justin Holewinski > Cc: Villmow, Micah; Tom Stellard; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] RFC: R600, a new backend for AMD GPUs > > On Mon, May 28, 2012 at 08:54:41AM -0700, Justin Holewinski wrote: > > On May 28, 2012 6:44 AM, "Tom Stellard" <thomas.stellard at amd.com> > wrote: > > > > > > On Fri, May 25, 2012 at 02:37:26PM -0700, Justin Holewinski wrote: > > > &g...

...or you to fetch changes up to 8d1fd61a3723ab8cb6b7bfeb8be38e16282cc1ed: > > > > nvidia: Add GM20B signed firmware (2016-02-23 18:48:41 +0900) > > > > These two patches add the NVIDIA-released firmwares necessary to enable > > rendering on desktop and mobile Maxwell 2 GPUs. Kernel support is ready > to > > be merged once this pull request is officially accepted. > > > > Pulled. Thanks Alexandre. > > regards, --Kyle > _______________________________________________ > Nouveau mailing list > Nouveau at lists.freedesktop.org > https...

...ed to drive, so > I did not want to muddy the water even more by giving register > addresses, rather concentrating on the problem at hand: How to compute > the duty value for the PWM controler. > >> >> We generally do this right, but appear to get it extra-wrong for certain GPUs. > > Yes... So far, we are always safe, but users tend to mind when their > computer sound like a jumbo jet at take off... Who would have thought? :D > > Anyway, looking forward to your answer! > > Cheers, > Martin Hi Martin, One of our firmware engineers thinks that t...

...ssible from the CPU on these routines. I think the easiest way of incorporating the power of the GPU into the model > fitting process would be to port the BLAS to the GPU. I also imagine that someone somewhere has already started on that. > I haven't seen anything more recent about using GPUs to compute for R, but NVIDIA just recently made available a beta of its CUDA environment for general-purpose computation on its new 8800-series GPUs, and there seems to be a BLAS library there. I tried to include links in this message, but I got "Message rejected by filter rule match" fr...