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

[lkcl]

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: 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.