Update README.md

README.md

@@ -15,3 +15,21 @@
 - Not supported: 3497/3888 (89.9%)  
 - Warnings:      0/3888 (0.0%)  
 (dEQP-VK.api.object_management.multithreaded_per_thread_device.buffer_view_uniform_r8g8b8a8_unorm runs out of memory, I need to get a RPi 3)
+
+## FAQ
+### Will this ever be a fully functional VK driver?
+As far as I know the PI is NOT fully VK capable on the hardware level. I can already see that some things will need to be emulated and others won't ever be emulated. The compiler is also a huge unknown at this point as I plan to write one from scratch.
+
+### What performance should you expect?
+Performance wise, the Pi is quite capable. The specs and architecture is close to the GPU in the iPhone 4s. The only problem I see is bandwidth as you only have about 7GB/s compared to 12-25GB/s on typical mobile phones. So post processing is a huge no and you'd need to be very careful about the techniques that you use. Eg. you'd need to stay on chip at all times. 
+CPU performance (eg. number of draw calls) should be enough on the quad-core PIs as you can easily utilise all cores using Vulkan.
+
+### What will be emulated?
+- I already plan to emulate a couple of the basics such as copy commands using compute
+- Tessellation and geometry shaders won't be considered, it just doesn't make sense
+- Sparse resources might be implemented, but I don't think performance would be great
+- Compute shaders could also be implemented, though I think I would need to modify the kernel side for that, no LDS or any of the fancy stuff though...
+- As far as I know the PI doesn't support occlusion queries (https://github.com/anholt/mesa/wiki/VC4-OpenGL-support)
+- Indirect draws are probably out of scope
+- I already added support (to be polished) to load shader assembly. This will enable devs to optimise shaders to the last cycle.
+- I'll probably add something to indicate towards the developer that things are emulated or not supported at all.