[libre-riscv-dev] [isa-dev] 3D Open Graphics Alliance

[lkcl]

On Monday, August 12, 2019 at 2:31:44 PM UTC+8, Jacob Lifshay wrote:
.
> 
> I personally think that having LLVM inline the corresponding
> implementations of the more complex operations is the better way to
> go. For most Vulkan shaders, they are compiled at run-time, so LLVM
> can do feature detection to determine which operations are implemented
> in the hardware and which ones need a software implementation.

Excellent that saves on develipment effort.

> This reduces the pressure on the opcode space by a lot.
> 
> > > From the SIGGRAPH BOF it was clear there are competing interests. Some people
> > > wanted explicit texture mapping instructions while others wanted HPC type
> > >  threaded vector extensions.
> >
> > interesting.
> 
> Having texture mapping instructions in HW is a really good idea for
> traditional 3D, since Vulkan allows the texture mode to be dynamically
> selected, trying to implement it in software would require having the
> texture operations use dynamic dispatch with maybe static checks for
> recently used modes to reduce the latency. See VkSampler's docs.

The one opcode that Mitch pointed out would be useful is the texture LD and interpolate. A 2D reference into a texture map plus an x scale and y scale.


> So, you overestimated the number of immediate bits needed by quite a lot.

I assumed a FMAC as worst case plus 2 bits per offset XYZW to simplify decode. 4 ops each a 4 vector @ 8 bit to swizzle all 4 vector elements is 32.

Either way it is mad extra immed bits meaning opcodes must be 48, 64 or even greater.

We can solve that wirh swizzle MV
L.

> Jacob