similar to: [PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at

Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: > > > On 03/14/2016 01:50 PM, Hans de Goede wrote: >> After pipe_grid_info.indirect was introduced, clover was not modified >> to set it causing it to pass uninitialized memory for it to launch_grid. >> >> This commit fixes this by zero-ing the entire pipe_grid_info struct when >> declaring it, to avoid similar

On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: > > > On 03/14/2016 02:26 PM, Hans de Goede wrote: >> Hi, >> >> On 14-03-16 14:01, Samuel Pitoiset wrote: >>> >>> >>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>> After pipe_grid_info.indirect was introduced, clover was not modified >>>> to set it causing it to pass

On 03/14/2016 01:50 PM, Hans de Goede wrote: > After pipe_grid_info.indirect was introduced, clover was not modified > to set it causing it to pass uninitialized memory for it to launch_grid. > > This commit fixes this by zero-ing the entire pipe_grid_info struct when > declaring it, to avoid similar problems popping-up in the future. > > Signed-off-by: Hans de Goede

On 03/14/2016 02:26 PM, Hans de Goede wrote: > Hi, > > On 14-03-16 14:01, Samuel Pitoiset wrote: >> >> >> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>> After pipe_grid_info.indirect was introduced, clover was not modified >>> to set it causing it to pass uninitialized memory for it to launch_grid. >>> >>> This commit fixes this by

Samuel Pitoiset <samuel.pitoiset at gmail.com> writes: > On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: >> >> >> On 03/14/2016 02:26 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 14-03-16 14:01, Samuel Pitoiset wrote: >>>> >>>> >>>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>>> After

Hi Daniel, In r172749 you removed the Linker::LinkInFiles() function and mentioned in the commit message that users of this function should migrate to "platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM linker." I'm trying to update this code: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clover/llvm/invocation.cpp to work with TOT

Hi, On 22-02-16 13:41, Samuel Pitoiset wrote: > Hi there, > > On 02/22/2016 12:26 PM, Hans de Goede wrote: <snip> >> So back to the problem of getting OpenCL(ish) code to work again with >> the recent mesa changes. For starters I would like to get: >> >> src/gallium/tests/trivial/compute.c and then the test with mask 8, >> test_input_global() to work

Hi, On 22-02-16 14:04, Samuel Pitoiset wrote: > > On 02/22/2016 01:46 PM, Hans de Goede wrote: >> Hi, >> >> On 22-02-16 13:41, Samuel Pitoiset wrote: >>> Hi there, >>> >>> On 02/22/2016 12:26 PM, Hans de Goede wrote: >> >> <snip> >> >>>> So back to the problem of getting OpenCL(ish) code to work again with

On Thu, Feb 14, 2013 at 04:41:41PM -0800, Daniel Dunbar wrote: > Hi Tom, > > From the context I am assuming you are in a JIT context, so the comments > about using a platform specific LTO mechanism don't apply. > > Were you using this code to extract bitcode files from archives, or just to > link in an individual bitcode file? > Hi Daniel, I was using this code to

Hi Tom, >From the context I am assuming you are in a JIT context, so the comments about using a platform specific LTO mechanism don't apply. Were you using this code to extract bitcode files from archives, or just to link in an individual bitcode file? - Daniel On Wed, Feb 13, 2013 at 12:24 PM, Tom Stellard <tom at stellard.net> wrote: > Hi Daniel, > > In r172749 you

Looking at /tools/llvm-link/llvm-link.cpp may give you some ideas here. I havent looked at your specific use case, but llvm-link uses ParseIRFile to pull in a bitcode file and build a Module for it. You can then create a Composite using the Module * and call Linker::LinkModules(Composite.get(), NewModuleToLink.get()... to link a new Module to your Composite Module. -Chris On Feb 14, 2013, at

On Tue, Dec 17, 2013 at 10:31:31AM +0000, Daniel Liew wrote: > Hi, > > We're currently upgrading KLEE to work with LLVM >=3.3 and we've hit a problem. > > It seems r172749 removed support for linking a bitcode archive into a > module. KLEE unfortunately depends on this to link in its runtime ( > which amongst other things provides a C library [5] ). > > A

Hi, I'm hitting that issue since Mesa 20.0.6 and it is present still in latest version 20.1.7 ``` [tkloczko at barrel SPECS]$ coredumpctl gdb 3926866 PID: 3926866 (test_va_api) UID: 1000 (tkloczko) GID: 1000 (tkloczko) Signal: 11 (SEGV) Timestamp: Sun 2020-09-13 18:57:06 BST (32s ago) Command Line: ./test_va_api Executable:

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

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.

Hi, We're currently upgrading KLEE to work with LLVM >=3.3 and we've hit a problem. It seems r172749 removed support for linking a bitcode archive into a module. KLEE unfortunately depends on this to link in its runtime ( which amongst other things provides a C library [5] ). A first attempt at linking in a bitcode archive ourselves can be seen in [1]. This approach does not work

This looks like the right idea to me too. It may sound a bit weird to do that per instruction, but d3d11 does that as well. (Some d3d versions just have a global flag basically forbidding or allowing any such fast math optimizations in the assembly, but I'm not actually sure everybody honors that without tesselation...) For 1/9: Reviewed-by: Roland Scheidegger <sroland at vmware.com>

On Thu, Mar 10, 2016 at 10:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Add support for clover / OpenCL kernel input parameters. > > Signed-off-by: Hans de Goede <hdegoede at redhat.com> > --- > .../drivers/nouveau/codegen/nv50_ir_from_tgsi.cpp | 18 +++++++++++++++--- > 1 file changed, 15 insertions(+), 3 deletions(-) > > diff --git