Re: [Mesa-dev] Loading Vulkan Driver

2020-08-22 Thread apinheiro 


On 21/8/20 7:27, vivek pandya wrote:
Thanks Jason for your time to reply. I understand the error but I am 
not much familiar with entry points generation code.



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). It C&P and adapted the python scripts that Jason wrote for anv 
(that was that radv and turnip also did, afaik), and then provided 
several empty implementation for several methods, and dummy structs for 
several objects. It is possible that you could wrote something more 
simplified as a starting point (like no debug methods), but not too much.



Currently I just make it compile (I just want to develop a broken 
pipeline quickly that just returns from the entry point) .



As Jason mentioned, a device and instance would be required. I really 
doubt that any vulkan program would be able to skip calling the methods 
that create them. Although those could be dummy too.



I will study the code. Is there any document to read about that? I 
want to understand how loaders and icd interact.


On Thu, Aug 20, 2020 at 9:46 PM Jason Ekstrand > wrote:


The error says pretty clearly what went wrong.  The loader looked for
the `vk_icdGetInstanceProcAddr` symbol and couldn't find it in your
so.  You need at least the basic Get*ProcAddr symbols or else the
loader can't do anything.  You'll also need device and instance
creation functions and possibly some of the queries before anything
will work.

On Thu, Aug 20, 2020 at 10:43 AM vivek pandya
mailto:vivekvpan...@gmail.com>> wrote:
>
> Hello,
>
> I have started building mesa Vulkan driver.
> I have started by copying amd/vulkan driver however I have just
kept only one file in build
> libresoc_pipeline.c
> I have only one method
>
> VkResult libresoc_CreateGraphicsPipelines(
>         VkDevice _device,
>         VkPipelineCache  pipelineCache,
>         uint32_t count,
>         const VkGraphicsPipelineCreateInfo*  pCreateInfos,
>         const VkAllocationCallbacks* pAllocator,
>         VkPipeline*  pPipelines)
> {
>         return VK_ERROR_UNKNOWN;
> }
>
> with few edits/commenting out code into files I am able to build
libvulkan_libresoc.so
>  but when I forced loaded driver with VK_ICD_FILENAMES I am
getting following error:
> however I was expecting to hit VK_ERROR_UNKNOWN. Anyone have any
ideas? Am I missing any file in the build setting?
>
> vivek@vivek-VirtualBox:~/install/share/vulkan/icd.d$ vulkaninfo
> ERROR: [Loader Message] Code 0 : loader_scanned_icd_add: Attempt
to retrieve either 'vkGetInstanceProcAddr' or
'vk_icdGetInstanceProcAddr' from ICD
/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so failed.
> Cannot create Vulkan instance.
> This problem is often caused by a faulty installation of the
Vulkan driver or attempting to use a GPU that does not support Vulkan.
>

/build/vulkan-tools-KEbD_A/vulkan-tools-1.2.131.1+dfsg1/vulkaninfo/vulkaninfo.h:371:
failed with ERROR_INCOMPATIBLE_DRIVER
>
> Thanks,
> Vivek
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org

> https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2020-08-22 Thread Luke Kenneth Casson Leighton 
On Sat, Aug 22, 2020 at 10:34 PM apinheiro  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

with thanks and gratitude,

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2020-08-22 Thread apinheiro 


On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote:

On Sat, Aug 22, 2020 at 10:34 PM apinheiro  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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

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

2020-08-22 Thread Luke Kenneth Casson Leighton 
On Sun, Aug 23, 2020 at 1:56 AM apinheiro  wrote:

> On 22/8/20 23:59, Luke Kenneth Casson Leighton wrote:
> > constructive feedback on this approach greatly appreciated:
> > https://bugs.libre-soc.org/show_bug.cgi?id=251#c36

> In any case, those steps look good enough, although I lack any context
> of the final target.

(if i can fill in this bit)

the context is: to augment the PowerISA Instruction set to add 3D
opcodes *directly* to PowerISA, with the guidance, full knowledge and
under the supervision of the OpenPOWER Foundation.

this will include:  adding sin, cos, atan2... *to PowerISA*.  adding
texture interpolation instructions... *to PowerISA*.  adding YUV2RGB
and FP32-to-RGB conversion instructions... *to PowerISA*.

therefore, whilst the initial target is "general purpose scalar
non-accelerated non-vectorised soft-3D", this is simply because the
next step is to add 3D opcodes *directly* to the POWER9 core that we
are developing.


i mention this because normally, GPUs are considered completely
separate entities - completely separate processors.  LibreSOC will be
the first ever libre-licensed *hybrid* 3D-capable CPU, i.e. where the
*main processor* ISA is augmented to no longer need a completely
separate GPU.

i appreciate that i have said the same thing in several different
ways.  this is because hybrid CPU/VPU/GPUs are so unusual and so "not
normal industry practice" (because they're easier to sell if they're
separate) that it takes a while to sink in.

i know of only one commercial company that has developed a hybrid
CPU/VPU/GPU (they called it a GPGPU - general purpose GPU) - by
ICubeCorp. back around 2012-2015 they received government funding
sufficient to complete the IC3128 and associated VLIW compiler.  an
SGI Engineer who went on to work for both AMD and NVidia created the
ISA and designed the architecture.

l.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev