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

[vivek pandya]

Hello all,

I just cleanup a bit and commited code at :
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f

However it is not working as per my expectation (or my expectations are
wrong)

I want to see that driver fail at
https://gitlab.freedesktop.org/vivekvpandya/mesa/-/commit/d1f29adf926eb44453db1255834575a6f7169d5f#54a82819ff146aa01755bf951d797d55a0332a32_0_43
however in debugger control never reach there.

I see that in
https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e
CreateShaderModule() is defined
I am defining libresoc_CreateGraphicsPipelines() and I want control to
reach here.

I need to debug more to know what part of code is responsible to call this
function.
Just to note I have not done much change in entrypoint generation /
extension generation python script so my doubt is that there something I am
missing.

Also when I commented to https://gitlab.freedesktop.org/vivekvpandya/mesa
it seems to be triggered CI/CD, for now I don't want that. Any way to
disable CI/CD triggers?

Thanks,
Vivek


On Sun, Aug 23, 2020 at 6:26 AM apinheiro <apinheiro at igalia.com> wrote:

>
> 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> <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).
>
I think compute shaders are the simplest things to get running with much
less setup compared to other shader types.

> 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 listmesa-dev at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>