[libre-riscv-dev] [isa-dev] Re: FP transcendentals (trigonometry, root/exp/log) proposal

[Andrew Waterman]

On Thu, Aug 8, 2019 at 11:03 PM lkcl <luke.leighton at gmail.com> wrote:

> On Friday, August 9, 2019 at 1:39:53 PM UTC+8, andrew wrote:
> > On Thu, Aug 8, 2019 at 8:12 PM lkcl <luke.l... at gmail.com> wrote:
> > On Thursday, August 8, 2019 at 10:14:58 PM UTC+8, andrew wrote:
> >
> >
> >
> > > As I mentioned earlier, an instruction being useful is not by itself a
> justification for adding it to the ISA. Where’s the quantitative case for
> these instructions?
> >
> >
> >
> > 3D is a Billion dollar mass volume market, proprietary GPUs are going
> after mass volume, inherently excluding the needs of (profitable) long-tail
> markets.
> >
> >
> > That’s a business justification,
>
> Yes it is. That's the start of the logic chain.
>
> > not an architectural one, and in any case it’s a justification for
> different instructions than the ones you’ve proposed.
>
> Andrew: I appreciate that you're busy



Good point - I capitulate.

: so am I. If you could give a little bit more detail, by spending the time
> describing a way forward instead of putting up barriers where we have to
> guess how to work around them, that would save a lot of time.
>
> For example, in order to move forward with a solution, I would expect such
> a statement above to include some sort of description or hint as to what
> the alternative instructions might look like.
>
> Then those can be formally evaluated to see if they meet first the
> business justification, then if that passes, the time can be spent on
> architectural evaluation.
>
> > The market you’re describing isn’t populated with products that have
> ISA-level support for correctly rounded transcendentals; they favor less
> accurate operations or architectural support for approximations and
> iterative refinement.
>
> Iterative pipelined refinements, in order to meet timing critical needs of
> [some] of the business requirements, yes.
>
> Andrew: the proprietary vendors are "custom" profiles. Their design
> approach gas to be excluded from consideration as something to follow.
>
> The proprietary vendors typically have conplete custom architectures.
> Custom ISAs. Even NVIDIA's new architecture fits the *custom* RISCV profile.
>
> This has a software development penalty due to the need to "marshall" and
> "unmarshall" the OpenGL / OpenCL / Vulkan API parameters on the userspace
> (x86/ARM/MIPS) side, stream them over to the GPU's memory space (typically
> over a PCIe PHY), and unpack them.
>
> The response to the API call goes through the exact same insane process.
> This so that, in the case of eg MALI, PowerVR, Vivante etc they can sell
> product independently of the main CPU ISA.
>
> We are proposing something that runs DIRECTLY ON THE PROCESSOR. I
> apologise I know you don't like capitals, I have written the above about
> eight or nine tines now over the past year and it's starting to get
> irritating that its significance is being ignored.
>
> Hybrid CPU / GPUs such as that proposed by Pixilica (and independently by
> our team) are much simpler to implement, make debugging far easier, and
> save hugely on development time.
>
> Hybrid CPU/GPU/VPUs therefore *need* - at the architectural level - a
> close tie-in to the host ISA. That's just how it has to be.
>
> And as high profile "open" products, the compiler tools also neef full
> upstream support for them.
>
> This is why they simply cannot and will not work as "custom" extensions. I
> have repeated this literally dozens of times for over 18 months.
> Eventually it will sink in.
>
> L.
>
> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V ISA Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to isa-dev+unsubscribe at groups.riscv.org.
> To view this discussion on the web visit
> https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3faac876-96d5-4844-9d54-3a2e3e38e194%40groups.riscv.org
> .
>