similar to: [RFC 0/9] Add precise/invariant semantics to TGSI

all subexpression inside an ir_assignment needs to be tagged as precise. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/mesa/state_tracker/st_glsl_to_tgsi.cpp | 80 ++++++++++++++++++++++++------ 1 file changed, 65 insertions(+), 15 deletions(-) diff --git a/src/mesa/state_tracker/st_glsl_to_tgsi.cpp b/src/mesa/state_tracker/st_glsl_to_tgsi.cpp index c5d2e0fcd2..19f90f21fe

Only implemented for glsl->tgsi. Other converters just set precise to 0. Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 3 +++ src/gallium/auxiliary/tgsi/tgsi_ureg.c | 14 +++++++--- src/gallium/auxiliary/tgsi/tgsi_ureg.h | 20 +++++++++++--- src/gallium/auxiliary/util/u_simple_shaders.c | 2 +-

Also some missing _src()s and cosmetic changes. --- src/gallium/programs/galliumut/Makefile | 5 + .../programs/galliumut/gen_uureg_opcodes.sh | 29 +++ src/gallium/programs/galliumut/uureg.h | 196 ++++---------------- 3 files changed, 71 insertions(+), 159 deletions(-) create mode 100644 src/gallium/programs/galliumut/gen_uureg_opcodes.sh diff --git

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g.

Need to adjust coordinates since the shader receives the array index as depth in z, but the TEX instruction expects it to be the second coordinate for a 1D array texture. This fixes fbo-generatemipmap-array. Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: "10.2" <mesa-stable at lists.freedesktop.org> --- src/gallium/drivers/nouveau/nv50/nv50_surface.c | 6 ++++++ 1

https://bugs.freedesktop.org/show_bug.cgi?id=80266 Priority: medium Bug ID: 80266 Assignee: nouveau at lists.freedesktop.org Summary: Undefined operation in tgsi_ureg.c left shift of 1 by 31 places cannot be represented in type 'int' Severity: minor Classification: Unclassified OS: Linux (All)

Extend the MEMORY file support to differentiate between global, local and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

Extend the MEMORY file support to differentiate between global, private and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

Hi, On 10-03-16 16:35, Aaron Watry wrote: > On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > >> Extend the MEMORY file support to differentiate between global, local >> and shared memory, as well as "input" memory. >> >> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a >> special

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- src/gallium/auxiliary/tgsi/tgsi_text.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/gallium/auxiliary/tgsi/tgsi_text.c b/src/gallium/auxiliary/tgsi/tgsi_text.c index 93a05568f4..c5fcb3283d 100644 --- a/src/gallium/auxiliary/tgsi/tgsi_text.c +++ b/src/gallium/auxiliary/tgsi/tgsi_text.c @@

Hi people, When working with some usdt C++ probes we have come across a few issues. Controlling USDT Function name: Putting in usdt probes into C++ code gives you the mangled enclosing function name for the probes Function name. Working around this can be a pain. You need to wrap your usdt probes in extern C functions and call these. Could we have an option to control the Function name for

Whilst trying out some D to get an insight into what is the most common reason for a given function to return, I have bumped into an error I don''t understand. The first take on what I was trying to do was: # dtrace -n ''fbt:ip:ip_input:return{@home[arg0] = count();}'' and all was well. The next step was: # dtrace -n

I''m interested in monitoring the amount of stack used by a multi-threaded program. I assume ''stackdepth'' built-in would be useful...but not sure. Been through demo''s, ToolKit, and internals..but it''s just not clicking for me yet. Not sure how to measure start/end of stack size dynamically...Anyone know how to break this down? This message posted from

I would like to know how to get access to errno when using pid provider to probe calls to libc functions like fopen(). The built-in errno appears to be only for system calls. What I''d like to be able to do is investigate where in an application I''m encountering EMFILE and what the stack looks like at the time. This message posted from opensolaris.org

Hi Here is System tap''s representives response to my comments and mine back to that list. Since it was on a public mailing list i''m reposting here, since there is obvious interest. James Dickens uadmin.blogspot.com ---------- Forwarded message ---------- From: James Dickens <jamesd.wi at gmail.com> Date: Sep 13, 2006 1:51 PM Subject: Re: Systemtap vs Dtrace web page

Hi, Chris (cc) and I try to get the SGE master monitor work with Apple Leopard dtrace. Unfortunately we are stuck with the error msg below. Anyone having an idea what could be the cause? What I can rule out as cause is function inlining for the reasons explained below. Background information on SGE master monitor implementation is under http://wiki.gridengine.info/wiki/index.php/Dtrace

This patch series adds the needed support for this extension to the various parts of mesa to finally enable it for nvc0. Dave Airlie (1): glsl: lower cull_distance into cull_distance_mesa Tobias Klausmann (10): glapi: add GL_ARB_cull_distance mesa/main: add support for GL_ARB_cull_distance mesa/prog: Add varyings for arb_cull_distance mesa/st: add support for GL_ARB_cull_distance