On Thu, Mar 26, 2015 at 10:17 PM, Jan Vesely <jan.ves...@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 <imir...@alum.mit.edu> wrote: >> > On Thu, Mar 26, 2015 at 8:50 PM, Rob Clark <robdcl...@gmail.com> wrote: >> >> On Thu, Mar 26, 2015 at 3:10 PM, Ilia Mirkin <imir...@alum.mit.edu> wrote: >> >>> On Thu, Mar 26, 2015 at 3:02 PM, Jason Ekstrand <ja...@jlekstrand.net> >> >>> wrote: >> >>>> On Thu, Mar 26, 2015 at 12:00 PM, Aditya Avinash >> >>>> <adityaavina...@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@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > > -- > Jan Vesely <jan.ves...@rutgers.edu> _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
