[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
http://bugs.libre-riscv.org/show_bug.cgi?id=91
--- 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
that.
> 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