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
2019-08-25 20:03:04 +02:00
- [x] uniforms for matrix multiplication and animation
- [x] texture coordinates and texture sampling
2019-09-22 17:46:05 +02:00
- [x] varyings
- [x] Multiple vertex attributes
2019-09-23 16:52:34 +02:00
- [x] Depth buffers
2019-09-23 18:51:46 +02:00
- [x] Stencil buffers
2019-09-23 21:27:32 +02:00
- [x] Indexed draw calls
2019-09-24 23:07:53 +02:00
- [x] blending
2019-12-14 20:34:31 +01:00
- [ ] mipmapping
2019-12-15 16:31:40 +01:00
- [ ] cube mapping
2020-01-31 21:44:04 +01:00
- [x] shadow mapping / depth texture sampling
2020-02-01 10:29:57 +01:00
- [ ] Multi threaded cmdbuf generation test
2019-07-05 22:19:59 +02:00
- [x] Shader compiler chain
2019-07-05 21:53:50 +02:00
- [x] QPU assembler / disassembler
2019-08-21 23:13:08 +02:00
- [x] Resources
- [x] Descriptor support
- [x] VkSampler support
2019-07-27 22:59:24 +02:00
- [x] Push constant support
2019-10-02 01:09:53 +02:00
- [x] Platform features
- [x] Layer support
2019-12-07 21:36:59 +01:00
- [ ] Emulated features
- [ ] Clear command support
- [ ] Copy command support
2020-02-18 23:01:17 +01:00
- [x] Render to texture features
2020-02-18 23:01:05 +01:00
- [x] VkRenderPass support
- [x] Subpass support
2020-02-17 00:14:19 +01:00
- [x] MSAA support
2020-02-24 23:07:52 +01:00
- [x] Performance
- [x] Performance counters
2019-07-05 22:19:59 +02:00
- [ ] Synchronization
- [ ] vkCmdPipelineBarrier support
2020-02-24 23:07:52 +01:00
- [ ] Secondary command buffers
2019-09-16 00:01:32 +02:00
- [ ] WSI
- [ ] Direct to display support
2019-12-12 22:56:06 +01:00
- [ ] Fixes
- [ ] Hardware bug workarounds
- [ ] Handle offsets wherever required
- [ ] Handle subresource ranges properly
- [ ] Handle allocation scopes properly
- [ ] Shader module creation might not be thread safe
2019-07-05 22:32:33 +02:00
- [ ] Try to pass as much of the VK CTS as possible with existing feature set
2019-12-14 21:37:58 +01:00
- [ ] Github pages
- [ ] Wiki
- [ ] Performance recommendations
- [ ] How to do blending, depth/stencil testing, attributes
2018-11-17 16:57:20 +01:00
## VK CTS progress
2019-02-09 17:20:14 +01:00
- Passed: 7894/67979 (11.6%)
- Failed: 878/67979 (1.3%)
- Not supported: 59206/67979 (87.1%)
- Warnings: 1/67979 (0.0%)
2018-11-17 17:39:13 +01:00
2019-02-09 17:24:29 +01:00
Conformance run is considered passing if all tests finish with allowed result
codes.
Following status
codes are allowed:
- Pass
- NotSupported
- QualityWarning
- CompatibilityWarning
2019-09-04 12:38:12 +02:00
There are about 470.000 conformance tests.
2018-11-17 17:39:13 +01:00
## FAQ
### Will this ever be a fully functional VK driver?
2019-09-15 16:14:09 +02:00
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.
2018-11-17 17:39:13 +01:00
### 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
2019-09-15 16:14:09 +02:00
### What features will not be supported?
- 3D textures
- sparse textures
- compute shaders (though could be supported to some extent if the kernel side would support it)
- occlusion queries (https://github.com/anholt/mesa/wiki/VC4-OpenGL-support)
2020-02-24 22:54:59 +01:00
- pipeline statistics
- timestamp queries (maybe with kernel support?)
2019-09-15 16:14:09 +02:00
- indirect draws
- spirv shaders
- events
- proper semaphore support
- tessellation shaders
- geometry shaders
- 32 bit indices
2019-09-23 20:50:31 +02:00
- instancing
2019-09-29 15:58:32 +02:00
- pipeline caches (doesn't make sense with assembly shaders)
2020-02-20 21:48:03 +01:00
- multiple color attachments
2020-02-20 23:49:27 +01:00
- HDR render targets and textures (lack of kernel support for 64bpp render target)
- ETC textures (lack of kernel support for 64bpp render target)
2020-02-24 23:20:57 +01:00
- timing blocks for profiling (kernel supports interrupts, but data needs to be routed to userspace ie. add tiler/renderer start/end timing to seqnos)
2019-09-15 16:14:09 +02:00
### What additional features will this driver support?
2018-11-17 17:39:13 +01:00
- 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.
2019-09-15 16:14:09 +02:00
- Videocore IV provides some performance counters these will be exposed
- Videocore IV supports some texture formats that are not present in the spec
2019-09-15 18:34:55 +02:00
- bw1: 1 bit black and white
- a4: 4 bit alpha
- a1: 1 bit alpha
- vector graphics support?
2019-12-08 16:41:34 +01:00
### Shader patching
The Broadcom Videocore IV needs a couple of operations to happen in shader code that might have fixed function hardware on other platforms.
These are:
- writing stencil state setup register
- writing depth value to depth buffer
- performing blending in software
- writing vertex parameter memory read and write setup registers
Since the project will not include a compiler, but rather works with an assembly based shader setup, I decided not to patch shaders based on the state provided to the driver, but rather let the developer have full control.
This means that regardless of what
- depth write state
- blending state
- stencil state
- vertex attribute state
is passed to the driver, this will not be reflected in the final behaviour unless the developer adds it to the assembly shaders.
Helper functionality will be provided to aid with encoding register values. Additionally, general documentation will be provided on how to perform these operations.
This will enable developers to take full control and optimise shaders to the last cycle.