[Mesa-dev] Summer of Code ideas (maybe just an idea wishlist?)

[Rob Clark]

On Thu, Mar 26, 2015 at 10:17 PM, Jan Vesely <jan.vesely at rutgers.edu> wrote:
> On Thu, 2015-03-26 at 21:11 -0400, Rob Clark wrote:
>> On Thu, Mar 26, 2015 at 8:59 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> > On Thu, Mar 26, 2015 at 8:50 PM, Rob Clark <robdclark at gmail.com> wrote:
>> >> On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> >>> On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand <jason at jlekstrand.net> wrote:
>> >>>> On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash
>> >>>> <adityaavinash1 at gmail.com> wrote:
>> >>>>> I mean, implementing fp64 on single precision systems.
>> >>>>
>> >>>> Ok, That makes more sense!  Having lowering passes for various FP64
>> >>>> operations would be great.
>> >>>
>> >>> We should make sure that there are customers of such work. It only
>> >>> makes sense to do this when everything else but FP64 are supported for
>> >>> GL 4.0 (including tess). r600 (eg/ni) is an obvious customer, although
>> >>> that may be easier to do in sb (I believe GlennK has been looking at
>> >>> it, not sure how far he's gotten). Other than that... not sure. Could
>> >>> be that Adreno A420 can do tess && has no native fp64 support, still
>> >>> need to figure that out (hasn't been RE'd yet).
>> >>
>> >> fwiw, fp64 lowering is almost certainly useful for a3xx when we get to
>> >> the point of doing compute..
>> >
>> > Why does compute need fp64? Do the blob drivers expose the fp64 capability?
>> >
>>
>> opencl (beyond embedded profile) requires fp64.. blob driver on a3xx
>> only supports embedded profile opencl (roughly everything *except*
>> fp64)..
>
> fp64 is required only for OpenCL 1.2+, embedded also makes int64, and
> atomic functions optional + precision of some built-in operations is
> relaxed.
> just my 2c
>

yeah, I had some confusion which ilia cleared up on irc (about int64 vs fp64)

thx

BR,
-R


> jan
>
>>
>> >>
>> >> (on that topic, TGSI or NIR support for clover would be kinda awesome
>> >> to get compute going on some drivers other than radeon.. probably TGSI
>> >> would be more immediately useful for more drivers, but not sure how
>> >> much would need to be added to TGSI, and NIR seems to be more
>> >> future-proof..)
>> >
>> > Before the whole SPIR-V thing, I had been toying with the idea of
>> > getting clover to spit out SPIR since llvm knew how to generate it.
>> > Now that SPIR-V is out, I think that's a more natural target and TGSI
>> > replacement. But all that is somewhat in the future. Curro tried to
>> > get llvm to spit out TGSI, but ended up running into trouble... that
>> > was a few years back.
>>
>> yeah, spir-v is another good option..  I would hope that by the time
>> freedreno's compiler backend is sophisticated enough to be useful for
>> compute, we have a spir-v -> nir translation of some sort.  Possibly
>> clover support for spir-v is the more future-proof approach to
>> bringing compute to more gallium drivers..
>>
>> BR,
>> -R
>>
>>
>> >
>> >   -ilia
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>
> --
> Jan Vesely <jan.vesely at rutgers.edu>