[Libre-soc-bugs] [Bug 230] Video opcode development and discussion

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Thu Dec 10 19:05:12 GMT 2020


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

--- Comment #6 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to cand from comment #4)
> > given that effectively SV is a 
> I don't think that's an efficient use of time.
> 
> The paradigms in the C and SIMD code for the loops often differ widely. The
> C is for understanding and correctness, SIMD for whatever is fastest for the
> platform. As such, basing the instruction guesses on the C could be
> suboptimal.

some SIMD ops which are highly weird yet do valuable tasks, i totally get. 
others are simply "N scalar ops".

needs thought at my end.  gimme time.


> The other part is complexity. The more developed codecs are highly complex,
> and having to page the stuff in and out of my head, without being able to
> write the actual code how it'd be targeted (SV, not PPC scalar, VSX, etc),
> would not be efficient.
> 
> I can go over the VSX funcs and check whether the idea under each is useful.
> 
> > what i'd like to do here is to check that general-purpose bitmanip could be 
> > used to cover all these types of pixel encodings, and to do a quick check / 
> > estimate on the pixels/clock rate.
> 
> It's just shifts, ands and ors. 

my concern is: how many? if that's 4 instructions in an inner loop then that
could well be 25% of the pixel/clock ratio that could be achieved if there was
a dedicated op that did the same.

but if pixel conversion is only say 1% of the total of an outer loop, that
doesn't matter.  if however the pixel conversion is 30% of total time *now* it
matters.


> Mul, madd, saturated add, narrowing and
> possibly LUTs if doing different colorspaces or gamma correction. All
> trivially parallelizable, so it depends on how many ops the unit can do in
> parallel.

this reminds me of the Khronos colour conversion which us nonlinear.  jacob
mentioned creating a LUT operation to cover this.

(In reply to cand from comment #5)
> The useful VSX parts are now on the wiki.

saw. thank you.  will look at later  got meeting now

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


More information about the libre-soc-bugs mailing list