[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 #45 from cand at gmx.com ---
> example: from LBS0 of input:
> 
> * skip N bits select M bits place in dest1
> * skip O bits select P bits place in dest2

I can't think of a good use for this capability. That's approaching office
document parsing, highly complex and in little need of vector speedup.

> it requires a lookup table.  hmm reluctant to include that. 

The Huffman tree is data-dependent, but not necessarily a big table. Canonical
Huffman can be encoded with just 4*maxlen aux data. If you were encoding bytes,
4*16*2 = 128 bits of aux data would let you do that. Canonical decoding has
similar low requirements.

A huffman encoding instruction wouldn't be that useful though. Media uses more
advanced methods, varying by codec. POWER has its gzip accelerator that packs
and unpacks with ludicrous speed, but it's gzip, not huffman.

> if however you are saying that even trying general purpose pixel-extraction is 
> not worth it (to support arbitrary future pixel encodings like 10 10 10, or... 
> i don't know) then i am happy to drop this.

Useful future formats are likely to be same-width, like 10-10-10. My scheme
would handle those. It's the per-element shift-mask, for different-width
elements, that may not have much use.

If it's easy for you to implement and doesn't take much hw space, the cost is
just one more opcode. I'm not against it per se, I just see little use for it.

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