Compiler and Rust related tasks for Summer of code
Hello, Congratulations! for being accepted for GSoC 2023 organization! Are the tasks related to compilation still relevant? Because on Trello board I see some very old edits too. Also are there any tasks which involve Rust? Thanks! Vivek
[Mesa-dev] Question in wsi_common_x11.c
Hello, In the following code why mage->base.row_pitches[0] is divided by 4 and passed as width to xcb_put_function() ? 26 static VkResult 25 x11_present_to_x11_sw(struct x11_swapchain *chain, uint32_t image_index, ... 15 14cookie = xcb_put_image(chain->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, 13 chain->window, 12 chain->gc, 11 image->base.row_pitches[0] / 4, 10 chain->extent.height, 9 0,0,0,24, 8 image->base.row_pitches[0] * chain->extent.height, 7 myptr); Thanks, Vivek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Question on ~/mesa/src/amd/llvm/ac_nir_to_llvm.c visit_load_var
I see that visit_load_var() in ~/mesa/src/amd/llvm/ac_nir_to_llvm.c assumes that nir_variable used in this intrinsic can have few specific mods only. For example variable can not have nir_var_mem_shared , if such mod encountered it will execute unreachable() code. Is there any nir pass that needs to be run before nir_to_llvm translation? Sincerely, Vivek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Understanding Components of SWR
Hello Jan, On Tue, Sep 15, 2020 at 12:45 PM Zielinski, Jan wrote: > > Is there any document for extending SWR for architectures other than > Intel? > > Unfortunately not. SWR was not architected to be portable beyond CPUs with > different levels of AVX ISAs. > > > It seems like SWR uses llvm_pipe shader creation, so is it still based > on tgsi IR to LLVM conversion? > > Yes, it is still based on TGSI. > > > Is there a path from NIR->LLVM (it seems so as per > https://phoronix.com/scan.php?page=news_item=LLVM-Switches-To-NIR-Default > ? > > For SWR no - it does not exist, at least not yet. From the top of my head, > I don't really know how much effort it would be to port SWR to NIR, but I > do plan to look into it. At some point... > > > Is the above idea possible at high-level? or I am missing lots of > important points? > > The most important point you may be missing is the fact that rasterization > in SWR is not based on LLVM. It based on AVX intrinsics (see code in > src/gallium/drivers/swr/rasterizer/core/). This is probably the biggest > problem if you target any other architecture. Most probably you would need > to rewrite the rasterizer to use LLVM IR or to some kind of language that > is based on LLVM and supports explicit vectorization, like ISPC. Rewriting > is most probably easier than convincing the community to introduce ISPC (or > any other new language) dependency to Mesa, though. ;-) > Thanks for the information. > > > Overall idea is to have SWR retargettable for any architecture that is > supported by LLVM codege and also don't want to use TGSI instead use NIR. > > Are you thinking about using SWR for Libre-SOC? > Yes but for now I am developing simple thing similar to https://github.com/baldurk/visor that is enough for experiments. > > BR, > Jan > > - > Intel Technology Poland sp. z o.o. > ul. Sowackiego 173 | 80-298 Gdask | Sd Rejonowy Gdask Pnoc | VII Wydzia > Gospodarczy Krajowego Rejestru Sdowego - KRS 101882 | NIP 957-07-52-316 | > Kapita zakadowy 200.000 PLN. > Ta wiadomo wraz z zacznikami jest przeznaczona dla okrelonego adresata i > moe zawiera informacje poufne. W razie przypadkowego otrzymania tej > wiadomoci, prosimy o powiadomienie nadawcy oraz trwae jej usunicie; > jakiekolwiek przegldanie lub rozpowszechnianie jest zabronione. > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). If you are not the intended > recipient, please contact the sender and delete all copies; any review or > distribution by others is strictly prohibited. > > ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Understanding Components of SWR
Hello, I would like to understand the high level architecture of SWR codebase. Is there any document for extending SWR for architectures other than Intel? It seems like SWR uses llvm_pipe shader creation, so is it still based on tgsi IR to LLVM conversion? Is there a path from NIR->LLVM (it seems so as per https://phoronix.com/scan.php?page=news_item=LLVM-Switches-To-NIR-Default ? If yes please point to the code? If not then How much effort will it take to get a NIR to LLVM IR converter? To get LLVM directly from NIR I am thinking to use RADV's NIR to LLVM IR converter but make it more suitable to generate LLVM IR for any other architecture by simply having a text file to look up for NIR to LLVM ir mapping and that makes RADV's LLVMIR generator target independent. If it is not one to one mapping then something more complex like LLVM's table gen can be used. Is the above idea possible at high-level? or I am missing lots of important points? Overall idea is to have SWR retargettable for any architecture that is supported by LLVM codege and also don't want to use TGSI instead use NIR. Thanks, Vivek ___ 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
Thank you Apinherio, Jason, Jacob, Dave and all other mesa devs for being patient with my questions. For now I am able to make progress with debug build of vulkan loader. There are still many things to learn. -Vivek On Mon, 24 Aug, 2020, 3:34 pm apinheiro, wrote: > > On 24/8/20 11:58, vivek pandya wrote: > > > > On Mon, Aug 24, 2020 at 3:26 PM apinheiro wrote: > >> >> On 24/8/20 11:39, vivek pandya wrote: >> >> >> >> On Mon, Aug 24, 2020 at 3:06 PM apinheiro wrote: >> >>> >>> On 24/8/20 11:23, vivek pandya wrote: >>> >>> Following output is generated due to my printfs. >>> >>> GetInstanceProcAddr called for: vkCreateInstance >>> GetInstanceProcAddr called for: vkEnumerateInstanceExtensionProperties >>> GetInstanceProcAddr called for: vkDestroyInstance >>> >>> Also I see the correct path from where ICD is being loaded. >>> >>> Where those printfs are placed? As far as I see those are on the loader >>> directly. My advice was about to put the printf on your vulkan method >>> implementations, to confirm if they are being called. >>> >> With Debugger I have checked that it reaches upto CreateInstance() >> implementation in my device.c >> >>> >>> I don't have any other vulkan tests for now. I will build mesa-demos and >>> test. >>> >>> >>> Then it will be really likely that more methods that the bare minimum >>> would be called. Taking into account that your plan is starting as small as >>> possible, I think that you should start writing a small vulkan test calling >>> as less as possible vulkan methods, even if it doesn't do anything at all. >>> At least until you get your vulkan methods implementation being properly >>> loaded and called. >>> >> Could you please recall how you have tested initial commits? >> >> >> Those commits were not enough to get any test working. As mentioned it >> was just the basic skeleton. Most of those methods are just empty stubs >> that doesn't do anything. So getting those methods called was the first >> starting point. >> >> After that, our objective was trying to get a really basic Vulkan tests >> working. As mentioned, we started with a real basic test that just did a >> clear, as in that way, we didn't need to bother with the compiler yet. We >> didn't save that test though. In any case, it was really simple, so it >> should be easy to recreate. >> > Okay I will write a very simple test. > One last thing, for your change and with simple test, were you able to > reach upto v3dv_CreateShaderModule() in debugger? > > > As I already mentioned (twice) that simple program only did a clear, so we > could test without needing to work on the compiler side of things yet. So > that program didn't even call v3dv_CreateShaderModule. > > BR > > > > Thanks, > Vivek > >> BR >> >> >> >>> >>> On Mon, Aug 24, 2020 at 2:44 PM apinheiro wrote: >>> >>>> >>>> On 24/8/20 10:25, vivek pandya wrote: >>>> >>>> Removing a few people who may not be interested in low level testing >>>> details. >>>> As far as >>>> https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e >>>> this commit is concerned following output seems correct as there are no >>>> extensions enabled so loader will just destroy the instance am I correct? >>>> >>>> >>>> I'm not sure why not having extension is related at all to what the >>>> loader does. That commit includes a basic implementation for that method. >>>> And as we are not supporting extensions, it is really likely that the >>>> output would be mostly empty. >>>> >>>> The loader would be just there to load the entrypoints. What your >>>> program does with the info coming from calling those methods it is >>>> independent of the loader. I really doubt the loader to do something like >>>> destroy the instance just because vkEnumerateInstanceExtensionProperties >>>> returns an empty set. It is more likely that it is your program the one >>>> calling vkDestroyInstance. >>>> >>>> >>>> DEBUG: Searching for ICD drivers named >>>> /home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so >>>> GetInstanceProcAddr called for: vkCreateInstance >>>> GetInstanceProcAddr called for: vkEnumerateInstanceExtens
Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver
More detailed log with VK_LOADER_DEBUG=1 INFO: Found ICD manifest file /home/vivek/install/share/vulkan/icd.d/libresoc_icd.x86_64.json, version "1.0.0" DEBUG: Searching for ICD drivers named /home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so GetProcAddr called for: vkCreateInstance GetProcAddr called for: vkEnumerateInstanceExtensionProperties DEBUG: Build ICD instance extension list libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) DEBUG: Instance Extension: VK_KHR_surface (/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so) version 0.0.25 DEBUG: Instance Extension: VK_KHR_display (/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so) version 0.0.23 DEBUG: Instance Extension: VK_EXT_direct_mode_display (/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so) version 0.0.1 DEBUG: Instance Extension: VK_EXT_display_surface_counter (/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so) version 0.0.1 DEBUG: Instance Extension: VK_EXT_debug_report (/home/vivek/install/lib/x86_64-linux-gnu/libvulkan_libresoc.so) version 0.0.9 DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest files: /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d:/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/ubuntu/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/var/lib/snapd/desktop/vulkan/implicit_layer.d:/home/vivek/.local/share/vulkan/implicit_layer.d DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest files: /etc/xdg/xdg-ubuntu/vulkan/implicit_layer.d:/etc/xdg/vulkan/implicit_layer.d:/etc/vulkan/implicit_layer.d:/usr/share/ubuntu/vulkan/implicit_layer.d:/usr/local/share/vulkan/implicit_layer.d:/usr/share/vulkan/implicit_layer.d:/var/lib/snapd/desktop/vulkan/implicit_layer.d:/home/vivek/.local/share/vulkan/implicit_layer.d DEBUG: ReadDataFilesInSearchPaths: Searching the following paths for manifest files: /etc/xdg/xdg-ubuntu/vulkan/explicit_layer.d:/etc/xdg/vulkan/explicit_layer.d:/etc/vulkan/explicit_layer.d:/usr/share/ubuntu/vulkan/explicit_layer.d:/usr/local/share/vulkan/explicit_layer.d:/usr/share/vulkan/explicit_layer.d:/var/lib/snapd/desktop/vulkan/explicit_layer.d:/home/vivek/.local/share/vulkan/explicit_layer.d INFO: Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_MESA_overlay.json, version "1.0.0" DEBUG: Adding VK_LAYER_LUNARG_standard_validation using the loader legacy path. This is not an error. INFO: Meta-layer VK_LAYER_LUNARG_standard_validation all 0 component layers appear to be valid. Is this version 0.0.25 and similar values look bad? On Sun, Aug 23, 2020 at 8:33 PM vivek pandya wrote: > > > > >> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 >> >> On Sun, Aug 23, 2020 at 10:36 AM vivek pandya >> wrote: >> > >> > 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. >> >> hm does it reach here? >> >> https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_device.c#L105 >> >> (can i recommend a #ifdef VERBOSE_DEBUG and some printfs: it's crude >> but effective and when restarting or when others try to replicate this >> they will not need to set large numbers of breakpoints. plus, the >> debug print statements become a discussion anchor / reference-point, >> and a form of documentation in themselves) >> >> about that: is there an "official" MESA macro for use to do verbose >> development-level debug output? i see the radv code checks an >> environment variable: >> >> https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/amd/vulkan/radv_device.c#L2569 >> >> >> >> > I see that in >> > >> https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e >> > CreateShaderModule() is defined >> >> hmm i don't see an equivalent createShaderModule in here: >> >> https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453d
Re: [Mesa-dev] [Libre-soc-dev] Loading Vulkan Driver
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68 > > On Sun, Aug 23, 2020 at 10:36 AM vivek pandya > wrote: > > > > 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. > > hm does it reach here? > > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_device.c#L105 > > (can i recommend a #ifdef VERBOSE_DEBUG and some printfs: it's crude > but effective and when restarting or when others try to replicate this > they will not need to set large numbers of breakpoints. plus, the > debug print statements become a discussion anchor / reference-point, > and a form of documentation in themselves) > > about that: is there an "official" MESA macro for use to do verbose > development-level debug output? i see the radv code checks an > environment variable: > > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/amd/vulkan/radv_device.c#L2569 > > > > > I see that in > > > https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e > > CreateShaderModule() is defined > > hmm i don't see an equivalent createShaderModule in here: > > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_pipeline.c > > also, enumerateInstanceDeviceProperties is empty: > > https://gitlab.freedesktop.org/vivekvpandya/mesa/-/blob/d1f29adf926eb44453db1255834575a6f7169d5f/src/libre-soc/vulkan/libresoc_device.c#L259 > > whereas it is not, here: > > https://gitlab.freedesktop.org/apinheiro/mesa/-/commit/07d01ebf6aae2f9ae71a8bea13a5d8acccb6280e#0b80c3a6757284417a6c75db460ee183cd5e80dd_0_35 > > i would recommend putting debug printfs at the top of > libresoc_GetInstanceProcAddr, to get a handle (ha ha) on what > functions are being looked for. ah: it *might* also be worthwhile > actually checking out that very early version of the broadcom driver, > liberally sprinkling it with debug printfs at least at the start of > every function, and see what is called, and in which order. > > by doing the same thing in the libresoc driver that would give you an > idea of what is missing. > > the other thought that occurred to me: it could just be that expecting > createGraphicsPipelines to be called is too early, and that to trigger > it, a little more of the infrastructure has to be in place, such as > responding to vkinfo: > > https://gitlab.axiodl.com/AxioDL/mesa/-/blob/abd629eb3d4027b89c13158e90c6732b412e550e/src/intel/vulkan/anv_device.c#L782 > > I added few debug statements but still the same result: Here is my debug log: vivek@vivek-VirtualBox:~/mesa/dbg$ vulkaninfo GetProcAddr called for: vkCreateInstance GetProcAddr called for: vkEnumerateInstanceExtensionProperties libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) GetProcAddr called for: vkCreateInstance GetProcAddr called for: vkEnumerateInstanceExtensionProperties libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) GetProcAddr called for: vkCreateInstance GetProcAddr called for: vkEnumerateInstanceExtensionProperties libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) libreSoc_EnumerateInstanceExtensionProperties called for layer: (null) GetProcAddr called for: vkEnumerateInstanceVersion GetProcAddr called for: vkDestroyInstance WARNING: WARNING: [Loader Message] Code 0 : terminator_CreateInstance: Failed to CreateInstance and find entrypoints with ICD. Skipping ICD. WARNING: terminator_CreateInstance: Failed to CreateInstance and find entrypoints with ICD. Skipping ICD. 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 I hope this is not due to the VirtualBox environment. just a thought. > > 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
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 wrote: > > 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). > 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
Re: [Mesa-dev] Loading Vulkan Driver
Thanks Jason for your time to reply. I understand the error but I am not
much familiar with entry points generation code. Currently I just make it
compile (I just want to develop a broken pipeline quickly that just returns
from the entry point) .
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
> 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_tcount,
> > 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] Loading Vulkan Driver
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_tcount,
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] Mesa Intel vulkan driver on VirtualBox
Hello, Is it possible to run a vulkan program on virtual box through libvulkan_intel.so ? I have build and installed latest mesa from git source but I get following output in vulkaninfo and vulkan-smoketest just fails with -3 error code. vivek@vivek-VirtualBox:~/mesa/dbg_opt$ vulkaninfo === VULKAN INFO === Vulkan API Version: 1.0.61 INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_unique_objects.json, version "1.1.0" INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_core_validation.json, version "1.1.0" INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_standard_validation.json, version "1.1.1" INFO: [loader] Code 0 : Encountered meta-layer VK_LAYER_LUNARG_standard_validation INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_object_tracker.json, version "1.1.0" INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_parameter_validation.json, version "1.1.0" INFO: [loader] Code 0 : Found manifest file /usr/share/vulkan/explicit_layer.d/VkLayer_threading.json, version "1.1.0" INFO: [loader] Code 0 : Meta-layer VK_LAYER_LUNARG_standard_validation all 5 component layers appear to be valid. INFO: [loader] Code 0 : Found ICD manifest file /usr/local/share/vulkan/icd.d/radeon_icd.x86_64.json, version "1.0.0" INFO: [loader] Code 0 : Found ICD manifest file /usr/local/share/vulkan/icd.d/intel_icd.x86_64.json, version "1.0.0" INFO: [loader] Code 0 : Found ICD manifest file /usr/share/vulkan/icd.d/radeon_icd.x86_64.json, version "1.0.0" INFO: [loader] Code 0 : Found ICD manifest file /usr/share/vulkan/icd.d/intel_icd.x86_64.json, version "1.0.0" Instance Extensions: Instance Extensions count = 14 VK_KHR_external_fence_capabilities : extension revision 1 VK_KHR_external_memory_capabilities : extension revision 1 VK_KHR_external_semaphore_capabilities: extension revision 1 VK_KHR_get_physical_device_properties2: extension revision 1 VK_KHR_get_surface_capabilities2: extension revision 1 VK_KHR_surface : extension revision 25 VK_KHR_wayland_surface : extension revision 6 VK_KHR_xcb_surface : extension revision 6 VK_KHR_xlib_surface : extension revision 6 VK_KHR_display : extension revision 23 VK_EXT_direct_mode_display : extension revision 1 VK_EXT_acquire_xlib_display : extension revision 1 VK_EXT_display_surface_counter : extension revision 1 VK_EXT_debug_report : extension revision 9 /build/vulkan-YO5iw0/vulkan-1.0.61.1+dfsg1/demos/vulkaninfo.c:1722: failed with VK_ERROR_INITIALIZATION_FAILED vivek@vivek-VirtualBox:~/mesa/dbg_opt$ vulkan-smoketest terminate called after throwing an instance of 'std::runtime_error' what(): VkResult -3 returned Aborted (core dumped) Any help? Thanks, Vivek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] AMD Vulkan driver entry point
Hello, I found following function: src/amd/vulkan/radv_pipeline.c 4998:VkResult radv_CreateGraphicsPipelines( but I could not find any caller to this function. Can someone please explain how this works? Thanks, Vivek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Questions related to NIR, LLVMPipe
Hello, According to https://en.wikipedia.org/wiki/Mesa_(computer_graphics) LLVMPipe driver is supposed to use NIR instead of TGSI. Is there any status update page? Is there any code for NIR parser/reader which can read text of NIR? Sincerely, Vivek ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
