<div dir="ltr">I'm assuming that control barriers in Vulkan are identical to barriers across a work-group in opencl. I was going to have a work-group be a single OS thread, with the different work-items mapped to SIMD lanes. If we need to have additional scheduling, I have written a javascript compiler that supports generator functions, so I mostly know how to write a llvm pass to implement that. I was planning on writing the shader compiler using llvm, using the whole-function-vectorization pass I will write, and using the pre-existing spir-v to llvm translation layer. I would also write some llvm passes to translate from texture reads and stuff to basic vector ops.<div><br></div><div>I have a prototype rasterizer, however I haven't implemented binning for triangles yet or implemented interpolation. currently, it can handle triangles in 3D homogeneous and calculate edge equations. <a href="https://github.com/programmerjake/tiled-renderer">https://github.com/programmerjake/tiled-renderer</a></div><div>A previous 3d renderer that doesn't implement any vectorization and has opengl 1.x level functionality: <a href="https://github.com/programmerjake/lib3d/blob/master/softrender.cpp">https://github.com/programmerjake/lib3d/blob/master/softrender.cpp</a></div><div><br></div><div>The scope that I intended to complete is the bare minimum to be vulkan conformant (i.e. no tessellation and no geometry shaders), so implementing a loadable ICD for linux and windows that implements a single queue, vertex, fragment, and compute shaders, implementing events, semaphores, and fences, implementing images with the minimum requirements, supporting a f32 depth buffer or a f24 with 8bit stencil, and supporting a yet-to-be-determined compressed format. For the image optimal layouts, I will probably use the same chunked layout I use in <a href="https://github.com/programmerjake/tiled-renderer/blob/master2/image.h#L59">https://github.com/programmerjake/tiled-renderer/blob/master2/image.h#L59</a> , where I have a linear array of chunks where each chunk has a linear array of texels. If you think that's too big, we could leave out all of the image formats except the two depth-stencil formats, the 8-bit and 32-bit integer and 32-bit float formats.</div><div><br></div><div>As mentioned by Roland Mainz, I plan to implement it so all state is stored in the VkDevice structure or structures created from VKDevice, so there are no global variables that prevent the library from being completely reentrant. I might have global variables for something like detecting cpu features, but that will be protected by a mutex.</div><div><br></div><div>Jacob Lifshay</div><br><div class="gmail_quote"><div dir="ltr">On Sun, Feb 12, 2017 at 3:14 PM Dave Airlie <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11 February 2017 at 09:03, Jacob Lifshay <<a href="mailto:programmerjake@gmail.com" class="gmail_msg" target="_blank">programmerjake@gmail.com</a>> wrote:<br class="gmail_msg">
> I would like to write a software implementation of Vulkan for inclusion in<br class="gmail_msg">
> mesa3d. I wanted to use a tiled renderer coupled with llvm and either write<br class="gmail_msg">
> or use a whole-function-vectorization pass. Would anyone be willing to<br class="gmail_msg">
> mentor me for this project? I would probably only need help getting it<br class="gmail_msg">
> committed, and would be able to do the rest with minimal help.<br class="gmail_msg">
<br class="gmail_msg">
So I started writing a vulkan->gallium swrast layer<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://cgit.freedesktop.org/~airlied/mesa/log/?h=not-a-vulkan-swrast" rel="noreferrer" class="gmail_msg" target="_blank">https://cgit.freedesktop.org/~airlied/mesa/log/?h=not-a-vulkan-swrast</a><br class="gmail_msg">
<br class="gmail_msg">
with the intention of using it to prove a vulkan swrast driver on top<br class="gmail_msg">
of llvmpipe eventually.<br class="gmail_msg">
<br class="gmail_msg">
This was because I was being too lazy to just rewrite llvmpipe as a<br class="gmail_msg">
vulkan driver,<br class="gmail_msg">
and it seemed easier to just write the layer to investigate. The thing<br class="gmail_msg">
about vulkan is it<br class="gmail_msg">
already very based around the idea of command streams and parallel<br class="gmail_msg">
building/execution,<br class="gmail_msg">
so having the gallium/vulkan layer record a CPU command stream and execute that<br class="gmail_msg">
isn't going to be a large an overhead as doing something similiar with<br class="gmail_msg">
hw drivers.<br class="gmail_msg">
<br class="gmail_msg">
I got it working with softpipe after adding a bunch of features to<br class="gmail_msg">
softpipe, however to<br class="gmail_msg">
get it going with llvmpipe, there would need to be a lot of work on<br class="gmail_msg">
improving llvmpipe.<br class="gmail_msg">
<br class="gmail_msg">
Vulkan really wants images and compute shaders (i.e. it requires<br class="gmail_msg">
them), and so far we haven't got<br class="gmail_msg">
image and compute shader support for llvmpipe. There are a few threads<br class="gmail_msg">
previously on this,<br class="gmail_msg">
but the main problem with compute shader is getting efficient barriers<br class="gmail_msg">
working, which needs<br class="gmail_msg">
some kind of threading model, maybe llvm's coroutine support is useful<br class="gmail_msg">
for this we won't know<br class="gmail_msg">
until we try I suppose.<br class="gmail_msg">
<br class="gmail_msg">
I'd probably be happy to mentor on the project, but you'd want to<br class="gmail_msg">
define the scope of it pretty<br class="gmail_msg">
well, as there is a lot of work to get the non-graphics pieces even if<br class="gmail_msg">
you are just ripping stuff<br class="gmail_msg">
out of llvmpipe.<br class="gmail_msg">
<br class="gmail_msg">
Dave.<br class="gmail_msg">
</blockquote></div></div>