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

[bugzilla-daemon at libre-soc.org]

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

--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to cand from comment #2)
> Before the binutils and simulator support exist, can't write the baseline
> simple-v code and so see which new instrs would be of most use. 

well... given that effectively SV is a hardware for-loop around scalar
code, could we start with the scalar inner loops, compile them to standard
scalar assembler, and take a look?

(more to the point: if that's *not* possible then it is a "red flag")

i was going to ask you if you could put the core inner loop of each algorithm
onto wiki pages (in straight c) as a first step.

> Otherwise
> it's just guesses, though I mentioned saturated math way back already.

ok. yes. although it's now "time" to start listing them.

> Or are you asking which parts of VSX are useful and which aren't?

mmm in terms of extracting from VSX, we're going to get questions,
"why are you not just using VSX" and for that i'd like - at some point -
to have a list of "equivalent ops" where anyone familiar with VSX can
see the SV alternatives, as (a) an easy cheat-sheet (b) an insight showing
that there is in fact direct equivalance (even if macro-op fusion is needed)

> The pixel VSX type is very rarely used. Personally I've never used it.
> Hardly anybody uses 16-bit color spaces nowadays, outputs are 24 (8-8-8) or
> even higher like 30 bit (10-10-10). It may not even have much use for
> textures, when a game needs to save bw it probably uses 5-6-5, 8-8 or fp16,
> not 5-5-5-1.

yes i kinda got that impression, i was wondering "where the heck are all the
other encodings" and the original (VMX) was developed between 1996 and 1998 (!)
with versions uprating that in 2006 (v2.03) and again in 2009 (v2.06).

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.

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