[Mesa-dev] Vulkan on CPU Google Summer of Code project
Jacob Lifshay
programmerjake at gmail.com
Tue Aug 29 03:35:43 UTC 2017
GSOC 2017 is effectively over for me, Here's the link to the GSOC landing
page that I will be submitting later:
https://github.com/programmerjake/vulkan-cpu/blob/gsoc-2017/docs/gsoc-2017-landing-page.md
I've only completed part of the Vulkan on CPU project:
- I've completely implemented generating the SPIR-V parser from Khronos's
JSON grammar description files.
- I've completely implemented using LLVM ORC as the JIT compiler back-end.
I implemented a ORC layer that integrates with the old JITEventListener
interface, allowing me to use LLVM's debugger integration.
- I've developed this project on GNU/Linux, so it has complete support.
- I've partially implemented translating from SPIR-V to LLVM IR.
- I've partially implemented generating a graphics pipeline by compiling
several shaders together.
- I've partially implemented image support: currently only
VK_FORMAT_B8G8R8A8_UNORM
- I have a temporary rasterizer implementation: I've implemented a scanline
rasterizer just to get stuff to draw, I'm planning on replacing it with the
originally-planned tiled binning rasterizer.
- I have less than 5 functions to implement before it will work on Win32,
mostly filesystem support.
- I've not yet started implementing the actual Vulkan ICD interface.
- I've not yet started implementing the Whole-function vectorization pass.
- I've not yet started implementing support for other platforms, however,
it should compile and run without problems on most Unix systems.
Some interesting things I learned:
- Vulkan doesn't actually specify using the top-left fill rule. (I couldn't
find it in the rasterization section of the Vulkan specification.)
- SPIR-V is surprisingly complicated to parse for an IR that's designed to
be simple to parse. OpSwitch requires you to determine the bit-width of the
value being switched on before you can parse the list of cases. See
https://bugs.freedesktop.org/show_bug.cgi?id=101560
I had gotten delayed by my implementing a SPIR-V parser myself. In
hindsight, the amount of time needed to run the SPIR-V to LLVM IR
translator is dwarfed by running LLVM's optimizations, so I could have just
used the SPIR-V parser that Khronos has already written as it's fast enough.
Jacob Lifshay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170829/82cf7e90/attachment.html>
More information about the mesa-dev
mailing list