[Libre-soc-bugs] [Bug 231] Video Opcodes Standards writeup

[bugzilla-daemon at libre-soc.org]

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

--- Comment #8 from Cole Poirier <colepoirier at gmail.com> ---
(In reply to Luke Kenneth Casson Leighton from comment #6)
> folks, just to clarify: this bugreport is for discussion of audio/video
> encode/decode specific instructions, and for their documentation and to
> track their submission to an OpenPOWER Foundation ISA Working Group. 

Yes sorry, that's my bad, I accidentally conflated the two when writing my
above comment.

> 3D GPU instructions, such as triangle detection, unless they can be
> demonstrated as needed for a video CODEC, are out of scope for this
> bugreport.  there will be another bugreport for discussion of 3D opcodes to
> be documented and submitted to OPF ISA WG.

Makes sense.

> also, Cole: the technique used by Jeff Bush in his Nyuzi paper is the most
> effective technique (calculating the pixels per clock achieved for a given
> enhancement).   measuring the effectiveness of an *existing* instruction set
> merely gives us a comparative baseline.  as we are doing a
> software-accelerated augmented ISA then just as in Jeff's Nyuzi work we can
> "profile" different areas of a CODEC and target those areas where
> alternative opcodes would give the highest bang per buck.

Pretty amazing work!! I finally finished reading his nyuzi rasterizer paper
last night and there are at least three (!!) mind-blowing revelations in the
last page alone. Definitely looking forward to chatting with you about your
conversations with Jeff Bush circa last year or the year before (I forget when
you wrote about having many discussions with him on a crowsupply update - or
somewhere else...). Thanks for the tip to check out his published literature :)
The method he outlines is very clever, very glad to have my misapprehensions
about the effectiveness of instruction counting corrected. There is genuinely
no better feeling than learning that there is a far better, more efficient, and
elegant way of going about something, and having it laid out for free and in
public in very great detail so that I can really study it.

> Lauri is correct in that we need at least binutils support (gnu as) for SV
> even to begin to start that assessment.  or at the very least a really bad
> hack which pre-processes assembler
> 
> that in turn means that we need realistically to do the SV-i-fication of
> POWER9 before being able to start this work in earnest.

With you. I mentioned that lu_zero at gentoo is working on a lot of media/video
encoding stuff and specifically working on the power side as well, with a good
amount of work on - if I'm not misremembering - binutils for power!! I'm
planning on reaching out to him this week. Should I send my draft email seeking
technical and correctness input on what I've written to the libre-soc-dev or
libre-soc-org mailing list?

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