1
0
mirror of https://github.com/Yours3lf/rpi-vk-driver.git synced 2024-12-01 13:24:20 +01:00
rpi-vk-driver/README.md

36 lines
2.3 KiB
Markdown
Raw Normal View History

2018-08-03 17:06:01 +02:00
# rpi-vk-driver
(not conformant yet, can't use official name or logo)
2018-08-26 15:49:21 +02:00
## Milestones
- [x] clear screen example working
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
2018-08-26 16:05:21 +02:00
- [ ] uniforms for matrix multiplication and animation
2018-08-26 16:06:04 +02:00
- [ ] texture coordinates and texture sampling
2018-09-09 16:50:08 +02:00
- [ ] shader compiled from spirv
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)
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.
2018-11-17 17:39:36 +01:00
CPU performance (eg. number of draw calls) should be enough on the quad-core PIs as you can easily utilise all cores using VK.
2018-11-17 17:39:13 +01:00
### 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.