[Libre-soc-dev] [Mesa-dev] Loading Vulkan Driver

[apinheiro]

On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote:
> On Sat, Aug 22, 2020 at 10:34 PM apinheiro <apinheiro at igalia.com> wrote:
>
>> As Jason mentioned, to get a Vulkan driver started, you would need more
>> than just one method. If you want a reference:
>>
>> https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e
>>
>> This commit added the basic skeleton for v3dv (broadcom mesa vulkan
>> driver).
> fantastic this is extremely helpful and much appreciated, thank you.
>
> some background: vivek has kindly agreed to start the NLNet-funded
> LibreSOC MESA Vulkan driver.  given that the LibreSOC CPU is a hybrid
> CPU/VPU/GPU with an augmented POWER9 ISA (rather than "a totally
> separate custom GPU with a foreign ISA completely incompatible with
> POWER9"), the first step is actually a general-purpose non-accelerated
> *software* Vulkan Driver, very similar to SwiftShader in concept
> except:
>
> * utilising NIR in order to take advantage of the 3D shader passes and
> the information it can hold
> * retaining vector, predication and texturisation intrinsics right up
> to the very last second when handing over to LLVM-IR
> * relying on "general" LLVM-IR to perform translation for *native*
> (host) execution - not a "totally separate custom GPU..."
> * initially entirely targetting *host* (native) scalar instructions
> [or, if general-purpose LLVM-IR happens to use NEON, SSE etc. that's
> great but not our concern]
>
> in other words it should be possible for the LibreSOC Vulkan driver to
> run on native non-accelerated CPUs - x86, POWER9, ARM, MIPS and so on.
>
> the second step will be to add custom 3D instructions *to POWER9*, at
> which point whilst we hope to retain the ability to still run on
> unaccelerated hardware, it is a secondary priority, albeit a very
> important one.
>
> as there may be questions "why not start from a different point, why
> not use SwiftShader or gallium" and so on, that evaluation took place
> here:
> https://bugs.libre-soc.org/show_bug.cgi?id=251
>
> constructive feedback on this approach greatly appreciated:
> https://bugs.libre-soc.org/show_bug.cgi?id=251#c36


Quoting from there:

 >  it should just return some error code as VkResult.

Not sure why it should return an error code. Even if initially is a 
no-op pipeline, if the method is able to create the object I think it is 
ok to return success, and let errors to be for real errors (out of 
memory, etc). But I guess that's ok if you prefer that until it starts 
to do something real.

 > Test this setup with by forcing application to use this driver. Need 
to figure out way how to force it. May be through VK_ICD_FILENAMES.

Yes you can do that with the VK_ICD_FILENAMES envvar.


 > Step3: Once we have above broken driver ready we can start enabling 
code required to process "COMPUTE" shaders.

Any specific reason to start with compute shaders? (mostly curiosity).

In any case, those steps look good enough, although I lack any context 
of the final target. The only thing that I miss is something like 
"writing the most basic vulkan program we can, and get it working with 
the driver". FWIW, when we did that for v3dv, we didn't even rendered 
anything, we just used clear/stores and confirmed that the output was 
correct. This allowed us starting with a basic driver that didn't even 
need a working backend compiler.

BR


>
> with thanks and gratitude,
>
> l.
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>