[libre-riscv-dev] [isa-dev] 3D Open Graphics Alliance
luke.leighton at gmail.com
Mon Aug 12 11:26:24 BST 2019
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
More information about the libre-riscv-dev