[libre-riscv-dev] [isa-dev] Re: Application for funding for RISC-V ISA development for Video Acceleration: Call for Participation

[Jacob Lifshay]

On Sun, Sep 22, 2019, 08:30 lkcl <luke.leighton at gmail.com> wrote:

>
>
> On Sunday, September 22, 2019 at 3:42:49 PM UTC+1, Jacob Lifshay wrote:
>>
>> On Sun, Sep 22, 2019, 02:34 lkcl <luke.l... at gmail.com> wrote:
>>
>>> On Saturday, September 21, 2019 at 11:58:18 AM UTC+1, lkcl wrote:
>>>>
>>>> Here is the preliminary writeup:
>>>> https://libre-riscv.org/nlnet_2019_video/
>>>
>>>
>>> it's in: with thanks to the person who contacted me.  i will keep people
>>> informed as to the progress of the application, over the next 1-3 months.
>>> if anyone would like to help fulfil the set goal and received donations for
>>> doing so, do get in touch, there is a lot to plan, between now and the
>>> [anticipated] start time somewhere around... jan 2020.
>>>
>>
>> YUV decoding/encoding is closely related to YCbCr decoding/encoding, both
>> of which will need to be supported texture modes for Vulkan, which means
>> that the texture read instructions should probably be used instead of using
>> dedicated yuv/ycbcr to/from rgb instructions.
>>
>
> good point... hum... let me think... i can imagine / foresee a potential
> scenario where people may not wish to utilise the texturisation opcodes
> that we're developing.  not just for ultra-low-power platforms fitting the
> new "3D Embedded" Profile, but implementors who just want a more
> stripped-down ISA.
>

sounds good. the texture opcodes will need to support dynamic format/mode
selection (Vulkan requirement), so it'll probably be good to have some
other opcodes that just share HW.

this also allows those that just want video encode/decode without 3D to do
that easily.

>
> i think what i am saying is: as a community we should investigate and
> evaluate both.
>

Sounds good.

Jacob

>