search for: texelfetch

Hi Christoph/nouveau folks, I've noticed that the piglit test "texelFetch" fails on my nv98 for sampler1DArray and sampler2DArray. I nuked the logic in nv50_ir_lowering_nv50.cpp:604 that does the f32 -> u32 conversion, and it seems to be passing now. TBH, I have no clue how the parameters are passed around and what that a[] is, but it seems like it's a u32 to...

...introduce additional non-uniformity in this argument. I'd appreciate input on this proposal, e.g. if this can be solved in an easier way or if there are obvious problems with this approach. Thanks, Nicolai .......... In a nutshell, the problem that this intends to solve is that: %v1 = texelFetch(%sampler, %coord0) %v2 = texelFetch(%sampler, %coord1) %v = select i1 %cond, vType %v1, %v2 is logically equivalent to and could benefit from being transformed to, %coord = select i1 %cond, cType %coord0, %coord1 %v = texelFetch(%sampler, %coord) but on the other hand %v1 = texel...

...ppreciate input on this proposal, e.g. if this can be solved in an easier way or if there are obvious problems with this approach. >> >> Thanks, >> Nicolai >> >> .......... >> In a nutshell, the problem that this intends to solve is that: >> >> %v1 = texelFetch(%sampler, %coord0) >> %v2 = texelFetch(%sampler, %coord1) >> %v = select i1 %cond, vType %v1, %v2 >> >> is logically equivalent to and could benefit from being transformed to, >> >> %coord = select i1 %cond, cType %coord0, %coord1 >> %v = texelFetch(%sa...

...easier way or if there are obvious problems with this approach. >>>> >>>> Thanks, >>>> Nicolai >>>> >>>> .......... >>>> In a nutshell, the problem that this intends to solve is that: >>>> >>>> %v1 = texelFetch(%sampler, %coord0) >>>> %v2 = texelFetch(%sampler, %coord1) >>>> %v = select i1 %cond, vType %v1, %v2 >>>> >>>> is logically equivalent to and could benefit from being transformed to, >>>> >>>> %coord = select i1 %cond, cType...

...gt; change preserves (or shrinks) the divergence set (on top of that, the > new value obviously has to be equal to the old one in single threaded > semantics). Turns out that this isn't actually sufficient. Consider this (admittedly convoluted) example: idx = input & 1 v0 = texelFetch(s[idx & 0], ...) v1 = texelFetch(s[idx | 1], ...) cond = trunc idx to i1 v = select i1 cond, v1, v0 transformed into idx = in & 1 v = texelFetch(s[idx], ...) has the same divergence set for the argument to texelFetch as defined in the quote above, but the transformat...

...divergence set (on top of that, the >> new value obviously has to be equal to the old one in single threaded >> semantics). > > > Turns out that this isn't actually sufficient. Consider this (admittedly > convoluted) example: > > idx = input & 1 > v0 = texelFetch(s[idx & 0], ...) > v1 = texelFetch(s[idx | 1], ...) > cond = trunc idx to i1 > v = select i1 cond, v1, v0 > > transformed into > > idx = in & 1 > v = texelFetch(s[idx], ...) > > has the same divergence set for the argument to texelFetch as define...

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 other texturing operations). In unlinked TSC mode (i.e. method 0x1234 == 0), my observation is that it desperately wants for a valid sampler to be bound to sampler slot 0. Of course I don't think TLD actu...

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

...I say "unbound" for Fermi / Tesla, I mean BIND_TSC(ACTIVE=0) (method 0x2400, bit 0 == 0). Kepler doesn't have that, so presumably you mean TLD will look at TSC ID == 0, irrespective of the TSC ID encoded into the texture handle. The sRGB thing is ... rather annoying. Especially since texelFetch has some kind of extra-specially-odd rule around sRGB conversion. I don't remember what it is, but it feels like this would potentially make it impossible to follow. But I guess going back in time and fixing the hw is also difficult. Can you confirm whether it will always look at slot 0, even...

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 th...

...i > kept the assert() there on purpose for now to actually make sure we are no > hitting such a case. Do i misread you now? :) >From my read of the code, we'd hit that case now with TXF on a 2D_ARRAY with a constant as the array element. i.e. a piglit with uniform sampler2DArray foo; texelFetch(foo, ivec3(1, 2, 3)); -ilia

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:

...e we are >>> no >>> hitting such a case. Do i misread you now? :) >> >> From my read of the code, we'd hit that case now with TXF on a >> 2D_ARRAY with a constant as the array element. i.e. a piglit with >> >> uniform sampler2DArray foo; >> texelFetch(foo, ivec3(1, 2, 3)); > > Tested this (hope i did the right thing) and the assert did not get > triggered, but i am still uncertain of this. > -> move the assert into the F32 case for U32/S32 just to make sure... > switch (i->sType) > case TYPE_F32: > assert(...) >...

...on 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 other texturing > operations). In unlinked TSC mode (i.e. method 0x1234 == 0), my > observation is that it desperately wants for a valid sampler to be > bound to sampler slot 0. Of course I don&...

...there on purpose for now to actually make sure we are no >> hitting such a case. Do i misread you now? :) > From my read of the code, we'd hit that case now with TXF on a > 2D_ARRAY with a constant as the array element. i.e. a piglit with > > uniform sampler2DArray foo; > texelFetch(foo, ivec3(1, 2, 3)); Tested this (hope i did the right thing) and the assert did not get triggered, but i am still uncertain of this. -> move the assert into the F32 case for U32/S32 just to make sure... switch (i->sType) case TYPE_F32: assert(...) ... other than that, we are not even...

...or without the saturate if we rely on the test, > assert(!i->saturate)'ing is the only thing that breaks the test you sure > meant: > > glsl-resource-not-bound 1DArray > glsl-resource-not-bound 2DArray > glsl-resource-not-bound 2DMSArray Hm, those are the only times that a texelFetch is done in piglit with a constant layer index, I guess.

Some shaders appear to extract bits using shift/and combos. Detect (some) of those and convert to EXTBF instead. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 66 +++++++++++++++------- 1 file changed, 46 insertions(+), 20 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp

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, > >

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Tested on NVE6. Very strange that it seems to use 8 bits for offsets, vs 4 bits used by texelFetch. But this passes the piglit tests. Will test on a NVCX before checking in, in case it's different there. (Although that'd be surprising, given the similarities between the 2 ISAs.) src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 13 +++++++++++-- src/gallium/drivers/nouveau...

...e rely on the test, >> assert(!i->saturate)'ing is the only thing that breaks the test you sure >> meant: >> >> glsl-resource-not-bound 1DArray >> glsl-resource-not-bound 2DArray >> glsl-resource-not-bound 2DMSArray > Hm, those are the only times that a texelFetch is done in piglit with > a constant layer index, I guess. Ok, i'll keep the saturates for (U/S)16 to for once satisfy the "dependency" you posted up there and to be future proof if somebody implements something similar(?) for the S16 one!