similar to: [PATCH] gm107/ir: take relative pfetch offset into account

On Tue, Dec 19, 2017 at 11:41 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > This is parallel to the pre-SM50 change which does this. Adjusts the > shuffles / quadops to make the values correct relative to lane 0, and > then splat the results to all lanes for the final move into the target > register. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >

This is parallel to the pre-SM50 change which does this. Adjusts the shuffles / quadops to make the values correct relative to lane 0, and then splat the results to all lanes for the final move into the target register. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Entirely untested beyond compilation. Should check bin/tex-miplevel-selection textureGrad Cube

https://bugs.freedesktop.org/show_bug.cgi?id=108032 Bug ID: 108032 Summary: nv50_ir_lowering_gm107.cpp:326: undefined reference to `nv50_ir::NVC0LoweringPass::loadMsAdjInfo32(nv50_ir::T exInstruction::Target, unsigned int, int, nv50_ir::Value*, bool)' Product: Mesa Version: git

The old way made it impossible for the optimizer to reason about what was going on. The new way is the same number of instructions (the neg gets folded into the cvt) but enables the optimizer to be cleverer if comparing to a constant (most common case). [The optimizer is presently not sufficiently clever to work this out, but it could relatively easily be made to be. The old way would have

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

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

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

For values above integer accuracy in floats, val - floor(val) might actually produce a value greater than 1. For such large floats, it's reasonable to be imprecise, but it's unreasonable for FRC to return a value that is not between 0 and 1. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 3 ++- 1 file changed, 2

Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: > For values above integer accuracy in floats, val - floor(val) might > actually produce a value greater than 1. For such large floats, it's > reasonable to be imprecise, but it's unreasonable for FRC to return a > value that is not between 0 and 1. > > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > --- >

Am 18.11.2014 um 15:05 schrieb Ilia Mirkin: > On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: >> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >>> For values above integer accuracy in floats, val - floor(val) might >>> actually produce a value greater than 1. For such large floats, it's >>> reasonable to be imprecise,

On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: > Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >> For values above integer accuracy in floats, val - floor(val) might >> actually produce a value greater than 1. For such large floats, it's >> reasonable to be imprecise, but it's unreasonable for FRC to return a >> value that

On 18/11/14 14:34, Roland Scheidegger wrote: > Am 18.11.2014 um 15:05 schrieb Ilia Mirkin: >> On Tue, Nov 18, 2014 at 8:54 AM, Roland Scheidegger <sroland at vmware.com> wrote: >>> Am 18.11.2014 um 05:03 schrieb Ilia Mirkin: >>>> For values above integer accuracy in floats, val - floor(val) might >>>> actually produce a value greater than 1. For such

Hi everyone, For reasons beyond the scope of this message, I'd like to append a NULL element to the end of a list. tmp0 <- list(a=1, b=NULL, c=3) append(tmp0, c(d=4)) ## works as expected append(tmp0, c(d=NULL)) ## list with a/b/c only Given that I could use tmp0$a <- NULL to remove 'a', I seem to understand why appending NULL returns me the original list... But how should I

Hello, I am working on a AVR backend and have a version up and running that will convert LLVM IR code to assembly code for my target. I have written a bunch of instructions from the AVR Instruction Set in AVRInstrInfo.td and not much else. In a simple test case I am attempting to compile (if that is the word you are supposed to use for this operation) test.ll: define i8 @foo(i8 %a, i8 %b) {

hi, list, I found AMDGPUPromoteAlloca calculates newly ptr as follows: std::tie(TCntY, TCntZ) = getLocalSizeYZ(Builder); Value *TIdX = getWorkitemID(Builder, 0); Value *TIdY = getWorkitemID(Builder, 1); Value *TIdZ = getWorkitemID(Builder, 2); Value *Tmp0 = Builder.CreateMul(TCntY, TCntZ, "", true, true); Tmp0 = Builder.CreateMul(Tmp0, TIdX); Value *Tmp1 =

Hi Bill, Thanks for working on this. Is there a reference for the function attribute uwtable, or is it to be defined as part of this effort? Thanks in advance Garrison On Jul 23, 2011, at 1:29, Bill Wendling wrote: > What? Yet another EH proposal?! This one is different from the others in that > I'm planning to start implementing this shortly. But I want your feedback! I've

OK, so there's a bunch of stuff in here. The geometry stuff is based on the work started by Bryan Cain and Christoph Bumiller. Patches 01-12: Add support for geometry shaders and fix related issues Patches 13-14: Make it possible for fb clears to operate on texture attachments with an explicit layer set (as is allowed in gl 3.2). Patches 15-17: Make ARB_texture_multisample work

Hi All, I am creating an instrumentation pass using LLVM libraries. I am using clang++ (version 2.9) to compile cpp code into LLVM bit code. When I generate the llvm bit code using clang++ using -O3, I get many instances of instructions that look like the following. br i1 icmp ne (i8* bitcast (i32 (i32)* @pthread_cancel to i8*), i8* null), label %bb23, label %bb25 Here three LLVM instructions

I'm cross-compiling for MIPS. The test-case is as simple as it can be: void foo() {} $clang -target mips64-octeon-linux -c -B path/to/cross/compiled/mips/assembler a.c And then I look at the object file: $ nm a.o 0000000000000020 t $tmp0 0000000000000000 T foo I would like to know what "$tmp0" is. Furthermore, if I pass -g to clang, I see a whole bunch of such symbols. Some of

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