<div dir="auto">forgot to add mesa-dev when I sent.</div><div class="gmail_quote">---------- Forwarded message ----------<br>From: "Jacob Lifshay" <<a href="mailto:programmerjake@gmail.com">programmerjake@gmail.com</a>><br>Date: Feb 12, 2017 6:16 PM<br>Subject: Re: [Mesa-dev] software implementation of vulkan for gsoc/evoc<br>To: "Dave Airlie" <<a href="mailto:airlied@gmail.com">airlied@gmail.com</a>><br>Cc: <br><br type="attribution"><div dir="auto"><div><br><div class="gmail_extra"><br><div class="gmail_quote">On Feb 12, 2017 5:34 PM, "Dave Airlie" <<a href="mailto:airlied@gmail.com" target="_blank">airlied@gmail.com</a>> wrote:<br type="attribution"><blockquote class="m_8453315558996650093quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8453315558996650093quoted-text">> I'm assuming that control barriers in Vulkan are identical to barriers<br>
> across a work-group in opencl. I was going to have a work-group be a single<br>
> OS thread, with the different work-items mapped to SIMD lanes. If we need to<br>
> have additional scheduling, I have written a javascript compiler that<br>
> supports generator functions, so I mostly know how to write a llvm pass to<br>
> implement that. I was planning on writing the shader compiler using llvm,<br>
> using the whole-function-vectorization pass I will write, and using the<br>
> pre-existing spir-v to llvm translation layer. I would also write some llvm<br>
> passes to translate from texture reads and stuff to basic vector ops.<br>
<br>
</div>Well the problem is number of work-groups that gets launched could be<br>
quite high, and this can cause a large overhead in number of host threads<br>
that have to be launched. There was some discussion on this in mesa-dev<br>
archives back when I added softpipe compute shaders.<br>
<div class="m_8453315558996650093quoted-text"></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I would start a thread for each cpu, then have each thread run the compute shader a number of times instead of having a thread per shader invocation.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_8453315558996650093quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8453315558996650093quoted-text"><br>
> I have a prototype rasterizer, however I haven't implemented binning for<br>
> triangles yet or implemented interpolation. currently, it can handle<br>
> triangles in 3D homogeneous and calculate edge equations.<br>
> <a href="https://github.com/programmerjake/tiled-renderer" rel="noreferrer" target="_blank">https://github.com/programmerj<wbr>ake/tiled-renderer</a><br>
> A previous 3d renderer that doesn't implement any vectorization and has<br>
> opengl 1.x level functionality:<br>
> <a href="https://github.com/programmerjake/lib3d/blob/master/softrender.cpp" rel="noreferrer" target="_blank">https://github.com/programmerj<wbr>ake/lib3d/blob/master/<wbr>softrender.cpp</a><br>
<br>
</div>Well I think we already have a completely fine rasterizer and binning<br>
and whatever<br>
else in the llvmpipe code base. I'd much rather any Mesa based project doesn't<br>
throw all of that away, there is no reason the same swrast backend couldn't<br>
be abstracted to be used for both GL and Vulkan and introducing another<br>
just because it's interesting isn't a great fit for long term project<br>
maintenance..<br>
<br>
If there are improvements to llvmpipe that need to be made, then that<br>
is something<br>
to possibly consider, but I'm not sure why a swrast vulkan needs a from scratch<br>
raster implemented. For a project that is so large in scope, I'd think<br>
reusing that code<br>
would be of some use. Since most of the fun stuff is all the texture<br>
sampling etc.<br>
<div class="m_8453315558996650093quoted-text"></div></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">I actually think implementing the rasterization algorithm is the best part. I wanted the rasterization algorithm to be included in the shaders, eg. triangle setup and binning would be tacked on to the end of the vertex shader and parameter interpolation and early z tests would be tacked on to the beginning of the fragment shader and blending on to the end. That way, llvm could do more specialization and instruction scheduling than is possible in llvmpipe now.</div><div dir="auto"><br></div><div dir="auto">so the tile rendering function would essentially be:</div><div dir="auto"><br></div><div dir="auto">for(i = 0; i < triangle_count; i+= vector_width)</div><div dir="auto">    jit_functions[i](tile_x, tile_y, &triangle_setup_results[i]);</div><div dir="auto"><br></div><div dir="auto">as opposed to the current llvmpipe code where there is a large amount of fixed code that isn't optimized with the shaders.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_8453315558996650093quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="m_8453315558996650093quoted-text"><br>
> The scope that I intended to complete is the bare minimum to be vulkan<br>
> conformant (i.e. no tessellation and no geometry shaders), so implementing a<br>
> loadable ICD for linux and windows that implements a single queue, vertex,<br>
> fragment, and compute shaders, implementing events, semaphores, and fences,<br>
> implementing images with the minimum requirements, supporting a f32 depth<br>
> buffer or a f24 with 8bit stencil, and supporting a yet-to-be-determined<br>
> compressed format. For the image optimal layouts, I will probably use the<br>
> same chunked layout I use in<br>
> <a href="https://github.com/programmerjake/tiled-renderer/blob/master2/image.h#L59" rel="noreferrer" target="_blank">https://github.com/programmerj<wbr>ake/tiled-renderer/blob/<wbr>master2/image.h#L59</a> ,<br>
> where I have a linear array of chunks where each chunk has a linear array of<br>
> texels. If you think that's too big, we could leave out all of the image<br>
> formats except the two depth-stencil formats, the 8-bit and 32-bit integer<br>
> and 32-bit float formats.<br>
><br>
<br>
</div>Seems like a quite large scope, possibly a bit big for a GSoC though,<br>
esp one that<br>
intends to not use any existing Mesa code.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">most of the vulkan functions have a simple implementation when we don't need to worry about building stuff for a gpu and synchronization (because we have only one queue), and llvm implements most of the rest of the needed functionality. If we leave out most of the image formats, that would probably cut the amount of code by a third.</div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="m_8453315558996650093quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font color="#888888"><br>
Dave.<br>
</font></blockquote></div><br></div></div></div>
</div>