[Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver
vivekvpandya at gmail.com
Sun Aug 23 09:36:10 UTC 2020
I just cleanup a bit and commited code at :
However it is not working as per my expectation (or my expectations are
I want to see that driver fail at
however in debugger control never reach there.
I see that in
CreateShaderModule() is defined
I am defining libresoc_CreateGraphicsPipelines() and I want control to
I need to debug more to know what part of code is responsible to call this
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
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?
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:
> This commit added the basic skeleton for v3dv (broadcom mesa vulkan
> 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
> * 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
> 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
> > 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
> with thanks and gratitude,
> mesa-dev mailing listmesa-dev at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mesa-dev