similar to: [PATCH mesa v2] 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. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/state_trackers/clover/core/kernel.cpp |

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

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

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

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

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.

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

On Thu, Mar 10, 2016 at 10:27 AM, Samuel Pitoiset <samuel.pitoiset at gmail.com> wrote: > > > On 03/10/2016 04:23 PM, Ilia Mirkin wrote: >> >> 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

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

On 04:27 PM - Mar 10 2016, Samuel Pitoiset wrote: > > > On 03/10/2016 04:23 PM, Ilia Mirkin wrote: > >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> > >>--- > >>

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: