[libre-riscv-dev] texture opcodes

[Jacob Lifshay]

I ended up replying at
http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-June/001669.html

On Tue, Jun 4, 2019, 17:22 Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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?
>
> l.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>