On 11:21 AM - Apr 18 2016, Hans de Goede wrote:
> Hi,
>
> On 17-04-16 22:27, Pierre Moreau wrote:
> >On 04:17 PM - Apr 17 2016, Ilia Mirkin wrote:
> >>On Sun, Apr 17, 2016 at 4:07 PM, Pierre Moreau
> >>wrote:
> >>>Ping :-)
> >>>
> >>>On 10:56 PM - Mar 19 2016, Pierre
Hi,
On 17-04-16 22:27, Pierre Moreau wrote:
On 04:17 PM - Apr 17 2016, Ilia Mirkin wrote:
On Sun, Apr 17, 2016 at 4:07 PM, Pierre Moreau wrote:
Ping :-)
On 10:56 PM - Mar 19 2016, Pierre Moreau wrote:
Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2`
On Sun, Apr 17, 2016 at 4:27 PM, Pierre Moreau wrote:
> On 04:17 PM - Apr 17 2016, Ilia Mirkin wrote:
>> On Sun, Apr 17, 2016 at 4:07 PM, Pierre Moreau wrote:
>> > Ping :-)
>> >
>> > On 10:56 PM - Mar 19 2016, Pierre Moreau wrote:
>> >> Generating a
On 04:17 PM - Apr 17 2016, Ilia Mirkin wrote:
> On Sun, Apr 17, 2016 at 4:07 PM, Pierre Moreau wrote:
> > Ping :-)
> >
> > On 10:56 PM - Mar 19 2016, Pierre Moreau wrote:
> >> Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2` makes the
> >> GPU
> >> unhappy.
On Sun, Apr 17, 2016 at 4:07 PM, Pierre Moreau wrote:
> Ping :-)
>
> On 10:56 PM - Mar 19 2016, Pierre Moreau wrote:
>> Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2` makes the GPU
>> unhappy. Instead, manually handle the conversion between 64-bit and
Ping :-)
On 10:56 PM - Mar 19 2016, Pierre Moreau wrote:
> Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2` makes the GPU
> unhappy. Instead, manually handle the conversion between 64-bit and 32-bit
> values, and use `cvt` to convert between the original target (resp. source)
> and
On 06:41 PM - Mar 19 2016, Ilia Mirkin wrote:
> On Sat, Mar 19, 2016 at 6:36 PM, Pierre Moreau wrote:
> > On 06:26 PM - Mar 19 2016, Ilia Mirkin wrote:
> >> On Sat, Mar 19, 2016 at 6:26 PM, Pierre Moreau
> >> wrote:
> >> > However, you could have
On Sat, Mar 19, 2016 at 6:36 PM, Pierre Moreau wrote:
> On 06:26 PM - Mar 19 2016, Ilia Mirkin wrote:
>> On Sat, Mar 19, 2016 at 6:26 PM, Pierre Moreau wrote:
>> > However, you could have some `long bar; char foo = convert_char_sat(bar);`
>> > in
>>
On 06:26 PM - Mar 19 2016, Ilia Mirkin wrote:
> On Sat, Mar 19, 2016 at 6:26 PM, Pierre Moreau wrote:
> > However, you could have some `long bar; char foo = convert_char_sat(bar);`
> > in
> > the OpenCL kernel.
>
> Sure, but the SPIR-V -> nv50/ir converter could be
On Sat, Mar 19, 2016 at 6:26 PM, Pierre Moreau wrote:
> However, you could have some `long bar; char foo = convert_char_sat(bar);` in
> the OpenCL kernel.
Sure, but the SPIR-V -> nv50/ir converter could be smarter about when
it generates the converts, no?
-ilia
On 06:06 PM - Mar 19 2016, Ilia Mirkin wrote:
> Where are these coming from? Could you perhaps not generate them in
> the first place?
Those are coming from the generated SPIR-V, of the following kernel for
example:
__kernel void global_id(__global int * out)
{
unsigned id =
Where are these coming from? Could you perhaps not generate them in
the first place?
On Sat, Mar 19, 2016 at 5:56 PM, Pierre Moreau wrote:
> Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2` makes the GPU
> unhappy. Instead, manually handle the conversion
Generating a `cvt u32 $r0 u64 $r1d` or a `cvt u64 $r0d u32 $r2` makes the GPU
unhappy. Instead, manually handle the conversion between 64-bit and 32-bit
values, and use `cvt` to convert between the original target (resp. source)
and 32-bit value. This happens to be the behaviour of NVIDIA's
13 matches
Mail list logo