similar to: [PATCH] nv50/ir: make sure to reverse cond codes on all the OP_SET variants

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Pretty sure there's nothing wrong with it, but it looks odd in the code. src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gk110.cpp | 2 ++ src/gallium/drivers/nouveau/codegen/nv50_ir_emit_gm107.cpp | 7 +++++-- src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nvc0.cpp | 2 ++ 3 files changed, 9 insertions(+), 2 deletions(-)

On 09.05.2015 07:35, Ilia Mirkin wrote: > This has started to happen more now that the backend is producing > KILL_IF more often. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- > .../drivers/nouveau/codegen/nv50_ir_peephole.cpp | 29 ++++++++++++++++++++++ > .../nouveau/codegen/nv50_ir_target_nv50.cpp | 2 ++ > 2 files changed, 31

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

Slowly we are getting to the point, that we miss enough optimization opportunities as the result of our own passes. For this we need to fix AlgebraicOpt to be able to handle mods on sources without creating new issues. The last patch enables looping opts. v2: update commit author Karol Herbst (3): nv50/ir: fix AlgebraicOpt for slcts with mods nv50/ir: handle logops with NOT in AlgebraicOpt

Slowly we are getting to the point, that we miss enough optimization opportunities as the result of our own passes. For this we need to fix AlgebraicOpt to be able to handle mods on sources without creating new issues. The last patch enables looping opts. Karol Herbst (3): nv50/ir: fix AlgebraicOpt for slcts with mods nv50/ir: handle logops with NOT in AlgebraicOpt nv50/ir: run some

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index bd60a84998..0de84fe9fc 100644 --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp +++

Unfortuantely we don't know if a particular load is a real 2d image (as would be a cube face or 2d array element), or a layer of a 3d image. Since we pass in the TIC reference, the instruction's type has to match what's in the TIC (experimentally). In order to properly support bindless images, this also can't be done by looking at the current bindings and generating appropriate

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp b/src/gallium/drivers/nouveau/codegen/nv50_ir_peephole.cpp index 4c92a1efb5..bd60a84998 100644 ---

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Untested beyond compiling a few shaders to see if they look like they might work. nvdisasm agrees with envydis's decoding of these things. Will definitely get ahold of a G200 to run tests on before pushing this. .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 94 ++++++++++++++++++---

Why this code doesn''t work as expected? It raises exceptions everytime. Tried with || operator, too. validates_each :x, :y do |record, attr| record.errors.add (attr, ''between 1 and 100'') if (attr.to_i>100 or attr.to_i<0) end -- They say money can''t buy happiness? Look at the smile on my face... ear to ear, baby!

hi , this can be done easily if (cond) expr ex:  > for (i in 1: 4)+ {+ if(i==2) print("a")+ if(i==2) print("b")+ } output : [1] "a"[1] "b" but i want this  if (cond) expr1 expr 2 i tried this :  > for (i in 1: 4)+ {+ if(i==2) (print("b") && print("a"))+ } output : [1] "b"Error in print("b") &&

Dear invaluable R-list, my present problem is arranging/removing some panels in a lattice plot. Please consider the following: df.data <- cbind.data.frame(expand.grid(SUBJ=1:5, TREAT=LETTERS[1:4], REF=letters[1:4] ) ) df.data <-

Dear R-users I have 5 dependent variables (y1 to y5) and one independent variable (x) and 3 conditioning variables (m, n, and 0). Each of the conditioning variables has 2 levels. I created 2*4 panel plots. xyplot(y1+y2+y3+y4+y5 ~ x | m*n*o,layout = c(4,2)) I would like to reorder the 8 panels. I tried to use index.cond (e.g., index.cond = list(c(1,3,2,4,5,7,6,8)) but it didn't work out.

This is indeed a bug. I get a different error on my machine. Until we solve this bug, as a workaround, you can use the <4 x float> type for which the vselect works. From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Fan Dawei Sent: Wednesday, October 19, 2011 10:10 To: LLVMdev at cs.uiuc.edu Subject: [LLVMdev] Error when cond of select instruction is

Hi Rotem, What do you mean by "you can use the <4 x float> type for which the vselect works". Do you mean that then back-end can correctly split the operands when it is a four elements vector? I've try that, but it still fails. On Wed, Oct 19, 2011 at 4:21 PM, Rotem, Nadav <nadav.rotem at intel.com> wrote: > This is indeed a bug. I get a different error on my

Why will this simple statement not work? I think I am following the documentation for if(cond) statements, and I have tried wrapping the cons.expr and alt.expr in {}, I get the same error. There is no example in the help file, and this is not covered in the Introduction to R, SimpleR or other tutorials I have looked into. mxx=max(cpx_list$nMV); mxy=max(trend_list$nMV); if (mxx>mxy) mxy=mxx

Hi LLVMdev, In the specification of llvm ir, the select operation can takes a condition of vector type, 'select' Instruction Syntax: <result> = select *selty* <cond>, <ty> <val1>, <ty> <val2> *; yields ty* *selty* is either i1 or {<N x i1>} Overview: The 'select' instruction is used to choose one value based on a condition,

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)

Some of the lowering steps we currently do for FILE_MEMORY_GLOBAL only apply to buffers, making it impossible to use FILE_MEMORY_GLOBAL for OpenCL global buffers. This commits changes the buffer code to use FILE_MEMORY_BUFFER at the ir_from_tgsi and lowering steps, freeing use of FILE_MEMORY_GLOBAL for use with OpenCL global buffers. Note that after lowering buffer accesses use the

Retrieving the high 32 bits of a signed multiply is rather annoying. It appears that the simplest way to do this is to compute the absolute value of the arguments, and perform a u32 x u32 -> u64 operation. If the arguments' signs differ, then negate the result. Since there is no u64 support in the cvt instruction, we have the perform the 2's complement negation "by hand".