rpi-vk-driver/README.md

# rpi-vk-driver
(not conformant yet, can't use official name or logo)

## Milestones
- [x] clear screen example working
- [x] triangle example working
  - [x] shader from assembly, vertices from vertex buffer object, no uniforms, color hardcoded
  - [ ] uniforms for matrix multiplication and animation
  - [ ] texture coordinates and texture sampling
  - [ ] shader compiled from spirv

## VK CTS progress
- Passed:        261/3888 (6.7%)  
- Failed:        130/3888 (3.3%)  
- 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.
updated readme not to use vulkan name 2018-08-03 17:06:01 +02:00			`# rpi-vk-driver`
			`(not conformant yet, can't use official name or logo)`
Update README.md 2018-08-26 15:49:21 +02:00
			`## Milestones`
			`- [x] clear screen example working`
Update README.md 2018-10-14 18:29:57 +02:00			`- [x] triangle example working`
			`- [x] shader from assembly, vertices from vertex buffer object, no uniforms, color hardcoded`
Update README.md 2018-08-26 16:05:21 +02:00			`- [ ] uniforms for matrix multiplication and animation`
Update README.md 2018-08-26 16:06:04 +02:00			`- [ ] texture coordinates and texture sampling`
Update README.md 2018-09-09 16:50:08 +02:00			`- [ ] shader compiled from spirv`
Update README.md 2018-11-17 16:57:20 +01:00
			`## VK CTS progress`
			`- Passed: 261/3888 (6.7%)`
			`- Failed: 130/3888 (3.3%)`
			`- 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)`
Update README.md 2018-11-17 17:39:13 +01:00
			`## 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.`