[Libre-soc-bugs] [Bug 546] data moving / merging Function Unit (FSM)

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=546

--- Comment #5 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #3)

> Texture read won't need to produce fp64 values unless the pixels are stored
> in fp64 (very uncommon).

whew.

> Plan on texture reads being able to efficiently be random access,

ok so if it's a single access, then that can go into the standard Vector FUs
(as a single VL=1) or Scalar FUs, no problem.

a bit of resources will be wasted, you'll be reading say 16 bits and dropping
them into the lower word of a 64 bit reg.  byte-level masking on the regfile
takes care of that.

so all no problem there: the reg #s can be allocated to make sure that RT%4 ==
RA%4 == RB%4 (the conditions for getting into the Vector FUs, even if VL=1). 
or, if that's not a priority, just be happy that the LD went into the scalar
FUs and accept the performance hit.

the problem comes when reading a longer sequence (VL>1, SUBVL>1) where the
operation crosses beyond a 64-bit (single reg).

this may be more of an issue for Video/Audio than it is for Texturisation.

> though in
> practice texture accesses will often be near previous accesses (though not
> sequential) so caching will be needed.

yes.

-- 
You are receiving this mail because:
You are on the CC list for the bug.