full vk seem possible?

[bibleuspro]

Hi and great repo's you have here.

I just thought I should ask for everyone else...how likely does it seem that you will be able to be full vulkan conformant? mainly thinking the status quo of unity 3d LWRP equivalent. (Light Weight Render Pipeline) This even at 10 fps on a pi zero would be a remarkable achievement. Or comparable Armory3D/Cycles/Kha Pi, or new bsframework.io

So... asking have you found anything that seems to be impossible hurdles to be fully vulkan yet?

[Yours3lf]

Hi,

thank you!

As far as I know the PI is NOT fully Vulkan 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.

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. Therefore I'd say a custom pipeline would be best. CPU performance (eg. number of draw calls) should be enough on the quad-core PIs as you can easily utilise all cores using Vulkan. If Doom3 could run on a Geforce 3, the PI could probably run it as well (in theory) https://www.youtube.com/watch?v=Qj3dPyk7hPI

• 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
• there are probably lots of misc stuff that can't be implemented
• I already added support (to be polished) to load shader assembly. This will enable devs to optimise shaders to the last cycle.

So in summary, it probably won't ever be conformant, but it might become usable if you stick to OpenGLES 2.0 functionality. I'll probably add something to indicate towards the developer that things are emulated or not supported at all.

[bibleuspro]

Awesome overview. Exactly what I needed. To clarify if devs stick to OpenGLES 2.0 functionality, and then port to vk when you have it flushed out, we would in theory see a performance boost correct? That is the a main feature of vk more performance on previous gen hardware.

I think once you get this info posted on readme and do a few more blog posts with some VC4, VC5/V3D, broadcom, v3d, gallium etc. keywords you'll see people use it. Also at least one picture.

As a bonus, I just saw this...not sure if it is real. https://www.youtube.com/watch?v=5U7ngoEa8oM Filament PBR model + glslViewer + raspberry Pi Zero

[Yours3lf]

I hope so! If I manage to get the compiler right then in theory you should get a boost just from the multithreaded command submission on the CPU side and more efficient memory allocation. GPU side performance would be same/better/worse depending on the compiler if the byte stream sent to the GPU is the same. We'll see, let me first finish what I started.

[ghost]

Thanks to your effort yours3lf.