[libre-riscv-dev] texture opcodes
programmerjake at gmail.com
Wed Jun 5 06:43:30 BST 2019
I ended up replying at
On Tue, Jun 4, 2019, 17:22 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> On Wed, Jun 5, 2019 at 1:14 AM Mitchalsup <mitchalsup at aol.com> wrote:
> > Luke,
> > I think you should really consider creating texture reference
> instructions. This would
> > dump a crap-load (tm) functionality into a new-different FU where you
> would throw
> > FP operands, use them as addresses, and deliver Quads of interpolated
> results (RGBA}.
> > Texture basically takes FP operands, uses them to index multiple levels
> of "texture memory"
> > (the FP int parts index) and interpolate between the levels, the FP
> fraction parts interpolate.
> > There are lots of special cases that are best handled by a HW FU.That
> HW-FU will be able to
> > recognize the special nature(s) of texture memory requests, and both
> minimize the instruction
> > count but also optimize memory efficiency, and avoid CPU<->cache memory
> ordering issues
> > "when you don't know".
> hmmm, it makes a lot of sense. it would mean creating special
> instruction opcodes specifically for covering them, which, if we're
> going to "optimise" that area with special texturising accelerated
> instructions, that has to be done anyway, so is no big deal.
> jacob what's your thoughts?
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev