On Tue, Feb 23, 2016 at 7:12 AM, Pierre Moreau wrote:
> On 11:43 AM - Feb 23 2016, Hans de Goede wrote:
>> Hi,
>>
>
> [snip]
>
>>
>> >You may have to add LOAD64/STORE64 for 64-bit
>> >addresses though. Or we could decree that all addressing on global
>> >memory shall be 64-bit (and thus read the .
On 11:43 AM - Feb 23 2016, Hans de Goede wrote:
> Hi,
>
[snip]
>
> >You may have to add LOAD64/STORE64 for 64-bit
> >addresses though. Or we could decree that all addressing on global
> >memory shall be 64-bit (and thus read the .xy components of the
> >address source).
>
> I would prefer to k
Hi,
On 22-02-16 17:59, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 11:50 AM, Hans de Goede wrote:
Hi,
On 22-02-16 17:13, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin
wrote:
On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede
wrote:
But assuming I'm right, what I'm prop
On Mon, Feb 22, 2016 at 11:50 AM, Hans de Goede wrote:
> Hi,
>
>
> On 22-02-16 17:13, Ilia Mirkin wrote:
>>
>> On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin
>> wrote:
>>>
>>> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede
>>> wrote:
>
> But assuming I'm right, what I'm proposing is that
Hi,
On 22-02-16 17:13, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede wrote:
But assuming I'm right, what I'm proposing is that instead of passing
the input in as a global buffer, to instead pass it in as a const
buffer
On Mon, Feb 22, 2016 at 11:07 AM, Pierre Moreau wrote:
>> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede
>> wrote:
>> >> But assuming I'm right, what I'm proposing is that instead of
>> >> passing
>> >> the input in as a global buffer, to instead pass it in as a const
>> >> buffer. As such inste
On Mon, Feb 22, 2016 at 11:00 AM, Ilia Mirkin wrote:
> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede wrote:
>>> But assuming I'm right, what I'm proposing is that instead of passing
>>> the input in as a global buffer, to instead pass it in as a const
>>> buffer. As such instead of sticking it
- Mail original -
> On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede
> wrote:
> >> But assuming I'm right, what I'm proposing is that instead of
> >> passing
> >> the input in as a global buffer, to instead pass it in as a const
> >> buffer. As such instead of sticking it into ->set_globa
On Mon, Feb 22, 2016 at 10:50 AM, Hans de Goede wrote:
>> But assuming I'm right, what I'm proposing is that instead of passing
>> the input in as a global buffer, to instead pass it in as a const
>> buffer. As such instead of sticking it into ->set_global_binding,
>> you'd stick it into ->set_con
Hi,
On 22-02-16 16:24, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 9:50 AM, Hans de Goede wrote:
Hi,
On 22-02-16 15:22, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede
wrote:
Hi,
On 22-02-16 14:47, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin
wro
On Mon, Feb 22, 2016 at 10:15 AM, Pierre Moreau wrote:
> Apart from Tesla which uses shared memory for passing the OpenCL user params,
> Fermi+ use const memory for that, and this is what Samuel's patches are doing
> (at least from what I remember).
Hmmm that puts a bit of a hole in my theo
On Mon, Feb 22, 2016 at 9:50 AM, Hans de Goede wrote:
> Hi,
>
>
> On 22-02-16 15:22, Ilia Mirkin wrote:
>>
>> On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede
>> wrote:
>>>
>>> Hi,
>>>
>>> On 22-02-16 14:47, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin
wrote:
Hello,
> On 22 Feb 2016, at 15:22, Ilia Mirkin wrote:
>
>> On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede wrote:
>> Hi,
>>
>>> On 22-02-16 14:47, Ilia Mirkin wrote:
>>>
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote:
INPUT is for shader inputs which come from fixed functi
Hi,
On 22-02-16 15:42, Samuel Pitoiset wrote:
Well the pipe_loader stuff is buggy in compute.c, I can't even
create a screen object... That's sad. It fails in pipe_loader_probe() & co.
It works for me on a kepler1 (GT740), at least before the dropping of
the RES support some of the tests from
Hi,
On 22-02-16 15:22, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede wrote:
Hi,
On 22-02-16 14:47, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote:
INPUT is for shader inputs which come from fixed function loaders.
This is not what you want. You
Well the pipe_loader stuff is buggy in compute.c, I can't even
create a screen object... That's sad. It fails in pipe_loader_probe() & co.
On 02/22/2016 02:08 PM, Hans de Goede wrote:
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
On Mon, Feb 22, 2016 at 9:17 AM, Hans de Goede wrote:
> Hi,
>
> On 22-02-16 14:47, Ilia Mirkin wrote:
>>
>> On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote:
>>>
>>> INPUT is for shader inputs which come from fixed function loaders.
>>> This is not what you want. You want CONST. Stick the input
Hi,
On 22-02-16 14:47, Ilia Mirkin wrote:
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote:
INPUT is for shader inputs which come from fixed function loaders.
This is not what you want. You want CONST. Stick the input params into
a constbuf, and you're done.
Oh, and in case it's not clear,
On Mon, Feb 22, 2016 at 8:45 AM, Ilia Mirkin wrote:
> INPUT is for shader inputs which come from fixed function loaders.
> This is not what you want. You want CONST. Stick the input params into
> a constbuf, and you're done.
Oh, and in case it's not clear, I think this should be done by the st,
n
On Mon, Feb 22, 2016 at 8:08 AM, Hans de Goede wrote:
> 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:
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:
So back to the problem of getting OpenCL(ish) code to work again with
the recent mesa changes.
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:
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
Hi,
On 22-02-16 13:41, Samuel Pitoiset wrote:
Hi there,
On 02/22/2016 12:26 PM, Hans de Goede wrote:
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
Hi there,
On 02/22/2016 12:26 PM, Hans de Goede wrote:
Hi,
On 19-02-16 20:43, Ilia Mirkin wrote:
On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede
wrote:
Hi,
On 18-02-16 17:39, Ilia Mirkin wrote:
On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede
wrote:
But this does not seem to be hooked up
Hi,
On 19-02-16 20:43, Ilia Mirkin wrote:
On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede wrote:
Hi,
On 18-02-16 17:39, Ilia Mirkin wrote:
On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede
wrote:
But this does not seem to be hooked up yet for nouveau.
Samuel has patches. See
https://cgit.
On Fri, Feb 19, 2016 at 5:36 AM, Hans de Goede wrote:
> Hi,
>
> On 18-02-16 17:39, Ilia Mirkin wrote:
>>
>> On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede
>> wrote:
>>>
>>> But this does not seem to be hooked up yet for nouveau.
>>
>>
>> Samuel has patches. See
>> https://cgit.freedesktop.org/~ha
Hi,
On 18-02-16 17:39, Ilia Mirkin wrote:
On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede wrote:
But this does not seem to be hooked up yet for nouveau.
Samuel has patches. See
https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3
Cool, I will take a look at those.
So so
On Thu, Feb 18, 2016 at 9:45 AM, Hans de Goede wrote:
> But this does not seem to be hooked up yet for nouveau.
Samuel has patches. See
https://cgit.freedesktop.org/~hakzsam/mesa/log/?h=arb_compute_shader_v3
>
> So some questions:
> -The commit by Samual says:
> This introduces TGSI_FILE_MEMORY
Hi Ilia and Samuel,
I rebased my mesa git tree today (it was getting a bit stale)
and after that src/gallium/tests/trivial/compute.c stopped
working as well as any opencl programs with the kernel in TGSI
(as clover on nouveau currently only supports having the kernel
in TGSI).
The problem is tha
29 matches
Mail list logo
