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 <apinhe...@igalia.com> wrote: > > On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote: > > On Sat, Aug 22, 2020 at 10:34 PM apinheiro <apinhe...@igalia.com> > <apinhe...@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@lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/mesa-dev > >
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
