Displaying 20 results from an estimated 800 matches similar to: "[RFC mesa] clover: Fix pipe_grid_info.indirect not being initialized"
2016 Mar 14
1
[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
2016 Mar 14
2
[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.
Signed-off-by: Hans de Goede <hdegoede at redhat.com>
---
src/gallium/state_trackers/clover/core/kernel.cpp |
2016 Mar 14
2
[PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
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
2016 Mar 14
2
[PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
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
2016 Mar 14
0
[PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
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
2016 Mar 14
0
[PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
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
2016 Mar 14
0
[PATCH mesa] clover: Fix pipe_grid_info.indirect not being initialized
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
2013 Feb 13
2
[LLVMdev] Alternative to Linker::LinkInFile()
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
2016 Feb 22
2
Dealing with opencl kernel parameters in nouveau now that RES support is gone
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
2013 Feb 15
2
[LLVMdev] Alternative to Linker::LinkInFile()
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
2016 Feb 22
4
Dealing with opencl kernel parameters in nouveau now that RES support is gone
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
2013 Feb 15
0
[LLVMdev] Alternative to Linker::LinkInFile()
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
2013 Feb 15
0
[LLVMdev] Alternative to Linker::LinkInFile()
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
2013 Dec 17
0
[LLVMdev] How to do bitcode archive linking correctly?
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
2016 Mar 10
3
[PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters
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
2016 Mar 10
3
[PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters
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
2016 Mar 10
1
[Mesa-dev] [PATCH mesa 2/3] tgsi: Add support for global / local / input MEMORY
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.
2013 Dec 17
3
[LLVMdev] How to do bitcode archive linking correctly?
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
2016 Mar 10
4
[PATCH mesa 3/3] nouveau: Add support for clover / OpenCL kernel input parameters
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>
> >>---
> >>
2016 Feb 22
2
Dealing with opencl kernel parameters in nouveau now that RES support is gone
Hi,
On 19-02-16 20:43, Ilia Mirkin wrote:
> On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede <hdegoede at redhat.com> wrote:
>> Hi,
>>
>> On 18-02-16 17:39, Ilia Mirkin wrote:
>>>
>>> On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede <hdegoede at redhat.com>
>>> wrote:
>>>>
>>>> But this does not seem to be hooked up