similar to: [PATCH] Autogenerate uureg opcode macros

Running Tomb Raider on Nouveau I found some flicker caused by ignoring precise modifiers on variables inside Nouveau. This series add precise/invariant handling to TGSI, which can be then used by drivers to disable certain unsafe optimisations which may otherwise alter calculations, which depend on having the same result across shaders. This series fixes this bug in Tomb Raider and one CTS test

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

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)

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

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,

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

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

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

Hello, I have my work on the nv vpe video decoder in a functional state. In case you didn't know this decoder accelerates mpeg2 video at the idct/mc level. I have verified that it works on nv40 hardware. I believe it works on nv30 hardware (and maybe some earlier hardware), but I cannot verify since I have none. I will reply with patches against the kernel, drm, ddx and mesa for

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

Hello, Here is my first speedup patch. Like 10-11%. No IDCT yet. Please feel free to comment my code or even better think about improvements. :) I belive my routines are not so bad, maybe one day they will be even more faster. What needs to be optimized is the loop filter fuction. I have no ideas now how to do it. It does not leave much space for parallel stuff, copying memory from lot of

Hello, Here is my first speedup patch. Like 10-11%. No IDCT yet. Please feel free to comment my code or even better think about improvements. :) I belive my routines are not so bad, maybe one day they will be even more faster. What needs to be optimized is the loop filter fuction. I have no ideas now how to do it. It does not leave much space for parallel stuff, copying memory from lot of

Hi Mathieu, On Tue, May 26, 2020 at 02:50:39PM -0600, Mathieu Poirier wrote: > Hi Guennadi, > > On Mon, May 25, 2020 at 04:44:58PM +0200, Guennadi Liakhovetski wrote: > > Linux supports running the RPMsg protocol over the VirtIO transport > > protocol, but currently there is only support for VirtIO clients and > > no support for a VirtIO server. This patch adds a

Hi Mathieu, On Thu, Sep 10, 2020 at 11:22:11AM -0600, Mathieu Poirier wrote: > Good morning Guennadi, > > On Thu, Sep 10, 2020 at 10:38:54AM +0200, Guennadi Liakhovetski wrote: > > Hi Mathieu, > > > > On Wed, Sep 09, 2020 at 04:39:46PM -0600, Mathieu Poirier wrote: > > > Good afternoon, > > > > > > On Wed, Aug 26, 2020 at 07:46:36PM +0200,