similar to: Tessellation shaders get MEM_OUT_OF_BOUNDS errors / missing triangles

One additional observation that I just made is that on GK208, the blob apparently doesn't use the result of S2R Rx, SR_INVOCATION_ID wholesale in TCS. It either passes it through a I2I.S32.S32 Rx, |Rx| (i.e. absolute value), or even more paradoxically, shl 2; shr 2; which removes the top *2* bits, rather than just the top 1. However I see no such behaviour on GF108. I'm going to test out

There's Renka's STRIPACK, and TRIPACK, respectively, ACM TOMS Algorithms 772 and 751, and there's the R package "deldir" which does the Delaunay for a plane, but does anyone have or know of the tessellation in R for a sphere? Also, is there a standard indexing scheme for Delaunay facets, and perhaps of edges in such facets? I'd expect that to be a publication reference,

This is enough to enable tessellation support on nvc0. It seems to work a lot better on my GF108 than GK208. I suspect that there's some sort of scheduling shenanigans that need to be adjusted for kepler+. Or perhaps some shader header things. Even with the GF108, I still get occasional blue triangles in Heaven, but I get a *ton* of them on the GK208 -- seemingly the same issue, but it's

Okay, been working with tripack, seems the most mature package for this. Got it to work well with their test data set - data(tritest). When i tried random numbers to explore further, i am getting some results that don't reconcile. example run this: library(tripack) y <- runif(100) x <- runif(100) vm <- voronoi.mosaic(x,y) plot(vm) par(new=T) plot(x,y,col='blue') when

Hi Robert, Thanks for the quick response! That goes in line with my observations which is that these things happen when using an ATOM/RED instruction. I've checked and rechecked that I'm generating ops with identical bits as what the proprietary driver does, however (and nvdisasm prints identical output). Could you advise what the proper way of indicating that the memory is

https://bugs.freedesktop.org/show_bug.cgi?id=80865 Ilia Mirkin <imirkin at alum.mit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Hard hang (GPC0/TPC0/MP |[NVE7] Hard hang |trap: MULTIPLE_WARP_ERRORS |(GPC0/TPC0/MP trap:

https://bugs.freedesktop.org/show_bug.cgi?id=80865 Aaron Plattner <aplattner at nvidia.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|aplattner at nvidia.com |nouveau at lists.freedesktop.o | |rg

https://bugs.freedesktop.org/show_bug.cgi?id=80865 --- Comment #6 from tethys at gmail.com --- localhost:~# rpm -qa | fgrep mesa mesa-libGL-10.1.5-1.20140607.fc20.i686 mesa-libglapi-10.1.5-1.20140607.fc20.x86_64 mesa-filesystem-10.1.5-1.20140607.fc20.x86_64 mesa-libglapi-10.1.5-1.20140607.fc20.i686 mesa-libGLU-9.0.0-5.fc20.x86_64 mesa-libgbm-10.1.5-1.20140607.fc20.x86_64

https://bugs.freedesktop.org/show_bug.cgi?id=80865 Martin Peres <martin.peres at free.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #8 from Martin Peres

Hi All, This series implements using double immediates in the nouveau codegen code. This turns the following (nvc0) code: 1: mov u32 $r2 0x00000000 (8) 2: mov u32 $r3 0x3fe00000 (8) 3: add f64 $r0d $r0d $r2d (8) Into: 1: add f64 $r0d $r0d 0.500000 (8) This has been tested with the 2 double shader tests which I just send to the piglet list. On a gk208 (gk110 / SM35)

Hi, I'm new to this mailing list so apologies if this is too basic. I have confocal images 512x512 from which I have extracted x,y positions of the coordiates of labelled cells exported from ImageJ as a.csv file. I also have images that define an underlying pattern in the tissue defined as areas of different pixel values 0 or 255 (also 512x512) I've exported these images as .txt

Hello R Users, I am trying to do a quadrat count defined by covariate properties in spatstat. I have read my elevation raster into R (from ascii) and converted to class "im" for use in spatstat. Now I have point data of class "ppp" which window is the same extent as the elevation image. I can conveniently plot the image and the points on the image as follows:

Hello R Users, I am trying to do a quadrat count defined by covariate properties in spatstat. I have read my elevation raster into R (from ascii) and converted to class "im" for use in spatstat. Now I have point data of class "ppp" which window is the same extent as the elevation image. I can conveniently plot the image and the points on the image as follows:

Hi, On 02-12-15 19:33, Samuel Pitoiset wrote: > > > On 12/02/2015 04:34 PM, Hans de Goede wrote: >> On 01-12-15, Samuel Pitoiset wrote: >> >> >>> Ok, here is a MMT trace of vectorAdd: >> >>> >> >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz >> >> >> >> Hi Hans, >> >> >>

Hello, I've recently come across an error reported by the GPU and would like to know what it means and especially what causes it to be triggered. Any information would be very useful: I'm seeing MP warp error 0x10 (appears in MP register 0x48). This is what we currently have in nouveau: <reg32 offset="0x048" name="TRAP_WARP_ERROR"> <!-- ctx-switched -->

Hi, On 04-12-15 09:54, Samuel Pitoiset wrote: > > > On 12/04/2015 09:45 AM, Hans de Goede wrote: <snip> >>> Please give a shot at this branch : >>> http://cgit.freedesktop.org/~hakzsam/mesa/log/?h=nvf0_compute >>> >>> It fixes the initialization of the compute state and allows me to >>> launch 'test_input_global' (ie. ./compute

Also, where's the exit op? Perhaps what's happening is that you don't have an exit and it just goes off executing into the ether? On Tue, Dec 15, 2015 at 12:00 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > A few things that stand out: > > 0: ld u32 %r219 c0[0x0000000000000000+0x0] (0) > > wtf is that 0x0000000000000 thing doing there? Was it a %rX which got

I believe that your problem is this: /*01a0*/ LD R8, [R8]; /* 0x8000000000821c85 */ That needs to be LD.E (and your ST's need to be ST.E). You're using a 32-bit gmem address, but you need to be using a 64-bit one. I believe the 32-bit ones work on fermi, but afaik not on Kepler. Cheers, -ilia On Wed, Dec 16, 2015 at 12:06 PM, Hans de Goede

Hi all, As part of my compute work I'm trying to get some TGSI compute code to work. The code from mesa/src/gallium/tests/trivial.c works. So now I'm trying to get a "native" tgsi kernel to run via clover, I'm using Francisco's nbody.c example for this: https://fedorapeople.org/~jwrdegoede/nbody.c Which does not work, at first I thought there was an issue with the

On 01-12-15, Samuel Pitoiset wrote: >>> Ok, here is a MMT trace of vectorAdd: >>> >>> https://fedorapeople.org/~jwrdegoede/vectorAdd.log.gz >> >> Hi Hans, >> >> Thanks a lot. > > Well, I didn't know but Martin has a GK208... > I just tested the compute support on his card and ... it works without > any changes. :-)