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

Jan Vesely jan.vesely at rutgers.edu
Thu Mar 26 19:17:21 PDT 2015


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

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>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20150326/573e6755/attachment.sig>


More information about the mesa-dev mailing list