[libre-riscv-dev] [Bug 91] Design and implement texturing opcodes for 3D graphics

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Sun Jun 9 01:45:09 BST 2019


--- Comment #3 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #2)

> This is one of the bigger tasks (several months of work) due to the sheer
> number of different texture formats that need to be implemented, so it will
> definitely need some budget, which I'll let Luke allocate.

 it sounds... like, to be honest, we need to have a serious think about

> Since I'm planning on implementing all the required formats in Rust as part
> of the Vulkan driver (since they need to work on x86 as well), we can split
> that out into a separate library to use for implementing the HW decoding as
> well. I think I could write it in such a way that we can generate both
> nmigen and LLVM IR from the same code.

 that would be really good.

> Additionally, the Rust code can be
> used as a Python library for testing purposes.

 as long as doing so does not interfere with formal proofs (clearly yosys
 cannot be made to critically depend on either python or a rust library).

 we have sfpy as a link to softfloat: "parallel mirroring" during simulations
 and checking simulated results against outside resources *is* the entire
 point of working in python, it's extremely convenient.

> I think we should support YCbCr textures, since they are commonly used in
> video formats.

 as we're doing a VPU as well, yes.

 yes on supporting as many texture formats as possible: we may however
 need to seriously prioritise.

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

More information about the libre-riscv-dev mailing list