similar to: texelFetch sampler1/2DArray on nv50 gallium

On Sun, Jan 11, 2015 at 5:08 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 11.01.2015 22:54, Ilia Mirkin wrote: >> >> On Sun, Jan 11, 2015 at 4:40 PM, Tobias Klausmann >> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, >>>

Hi all, Some brain-storming on an issue with SPMD/SIMT backend support where I think some additional IR attributes would be useful. Sorry for the somewhat long mail; the short version of my current thinking is that I would like to have the following: 1) convergent: a call to a function with this attribute cannot be moved to have additional control dependencies; i.e., moving it from A to B is

On 24.10.2016 21:54, Mehdi Amini wrote: >> On Oct 24, 2016, at 12:38 PM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Some brain-storming on an issue with SPMD/SIMT backend support where I think some additional IR attributes would be useful. Sorry for the somewhat long mail; the short version of my current thinking is that I would like to have the following:

> On Oct 24, 2016, at 4:15 PM, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On 25.10.2016 01:11, Nicolai Hähnle wrote: >> On 24.10.2016 21:54, Mehdi Amini wrote: >>>> On Oct 24, 2016, at 12:38 PM, Nicolai Hähnle via llvm-dev >>>> <llvm-dev at lists.llvm.org> wrote: >>>> Some brain-storming on an issue with SPMD/SIMT backend

On Sun, Jan 11, 2015 at 5:48 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 11.01.2015 23:12, Ilia Mirkin wrote: >> >> On Sun, Jan 11, 2015 at 5:08 PM, Tobias Klausmann >> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> On 11.01.2015 22:54, Ilia Mirkin wrote: >>>>

On 25.10.2016 16:28, Nicolai Hähnle wrote: > But I fear that this path leads to eternal fuzziness. Let me try a > completely different approach to define what we need by augmenting the > semantics of IR with "divergence tokens". In addition to its usual > value, every IR value carries a "divergence set" of divergence tokens. > > The basic rule is: the

On 11.01.2015 23:12, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 5:08 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 22:54, Ilia Mirkin wrote: >>> On Sun, Jan 11, 2015 at 4:40 PM, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>> Folding for conversions:

On Sun, Jan 11, 2015 at 4:40 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > Folding for conversions: F32->(U{16/32}, S{16/32}) and (U{16/32}, {S16/32})->F32 > > Signed-off-by: Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> > --- > V2: Split out F64 parts > V3: remove handling of saturate for (U/S)32, > >

Hi Andy, Thanks for checking! I do see an issue on Tesla as well (at least G92, and I believe someone else reported on a GT215 or GT218). However I haven't confirmed that it's the identical issue to what I see on Fermi with quite as much certainty as what I've checked on a GF108. (For the G92, the texture buffer object test fails in the same way it does on Fermi, but there could be

Hello, This question is in the context of Tesla / Fermi generations, which have explicit bindings for textures / samplers. It might also apply to Kepler+, not quite as sure due to the bindless nature. I've been trying to understand how the TLD operation works (which is used to implement texelFetch in GLSL). It does not appear to the op takes an explicit sampler id at all (unlike all the

Fixes the texelFetch piglit tests. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Verified a few things, but it's hard to check this fully. They array-texture piglit test fails if the conversion isn't done at all, and texelFetch starts passing if the conversion is removed. Dunno if this is the sort of thing worth sticking a stable tag on, so leaving it out. Feel free to

(I work on CUDA / PTX.) For one thing I'm in favor of having fewer annotations rather than more, so if we can do this in a reasonable way without introducing the notion of co-convergent calls, I think that would be a win. The one convergent annotation is difficult enough for the GPU folks to grok and then keep in cache, and everyone who works on llvm has to pay the cost of keeping their

https://bugs.freedesktop.org/show_bug.cgi?id=102382 Bug ID: 102382 Summary: nv50ir: isImmediate doesn't properly work for integers if Value is typed as float Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

On 11.01.2015 20:19, Ilia Mirkin wrote: > On Sun, Jan 11, 2015 at 12:27 PM, Tobias Klausmann > <tobias.johannes.klausmann at mni.thm.de> wrote: >> >> On 11.01.2015 01:58, Ilia Mirkin wrote: >>> On Fri, Jan 9, 2015 at 8:24 PM, Tobias Klausmann >>> <tobias.johannes.klausmann at mni.thm.de> wrote: >>>> Folding for conversions:

Right now we emit on every kick, but this is only necessary if something will ever be able to observe that the fence completed. If there are no refs, leave the fence alone and emit it another day. This also happens to work around an issue for the kick handler -- a kick can be a result of e.g. nouveau_bo_wait or explicit kick, or it can be due to lack of space in the pushbuf. We want the emit to

On Sun, Jan 11, 2015 at 2:56 PM, Tobias Klausmann <tobias.johannes.klausmann at mni.thm.de> wrote: > > > On 11.01.2015 20:19, Ilia Mirkin wrote: >> >> On Sun, Jan 11, 2015 at 12:27 PM, Tobias Klausmann >> <tobias.johannes.klausmann at mni.thm.de> wrote: >>> >>> >>> On 11.01.2015 01:58, Ilia Mirkin wrote: >>>>

Fixes crash during reclocking. Call Trace: pll_calc == NULL calc_pll calc_mclk nv50_pm_clocks_pre nouveau_pm_perflvl_set nouveau_pm_trigger nouveau_pm_profile_set nouveau_pm_set_perflvl dev_attr_store sysfs_write_file vfs_write sys_write system_call_fastpath Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- It's weird nobody noticed this... nva3+ code does

The nvc0 texfetch instruction expects the sample id to be in the second source (usually used for the offset) rather than as part of the texture coordinate. This fixes all the sampler2DMS/Array tests on nvc0. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.1" <mesa-stable at lists.freedesktop.org> --- Tested on nvc1 with a full piglit run, no regressions,

https://bugs.freedesktop.org/show_bug.cgi?id=90348 Bug ID: 90348 Summary: Spilling failure of b96 merged value Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at

Create the ref_bo without any storage type flags set for now. This can probably be split up somehow later on, but this seems to work. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.0" <mesa-stable at lists.freedesktop.org> --- Would be great if someone could see if this also makes MPEG4 work on NVA3+. In order to do that, remove the if (chipset < 0xc0)