[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 #6 from Jacob Lifshay <programmerjake at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #5)
> (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).

That's the least of your problems, since each texture access can access 4 or 8
(or even more -- think 128 for anisotropic filtering) texels and linearly
interpolate between them. We will probably want a dedicated texture decode
pipeline, since texture access is the most critical part for GPU speed since
multiple of those full texture accesses can occur per drawn pixel.

Luckily texture interpolation only happens for fp16/fp32 results, so integer
results are just 1 texel access.

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