gpuopen-drivers/pal

Platform Abstraction Library

pal's Issues

Cleanup of CreateMemoryPoolAndSubAllocate does not handle OOM properly

The Vulkan CTS has a number of OOM tests that caused double-free errors in InternalMmeMgr. CreateMemoryPoolAndSubAllocate tries to access uninitialized pointers and tries to free them.

Following snippet of code gets executed when the pool creation fails, here pInternalMemory would be uninitialized on failure.

else
    {
        auto it = pOwnerList->Begin();
        bool needEraseFromOwnerList = pOwnerList->NumElements() > 0 ?
            (it.Get()->groupMemory.PalMemory(DefaultDeviceIndex) ==
             pInternalMemory->groupMemory.PalMemory(DefaultDeviceIndex)) : false;

        // Unmap any persistently mapped memory
        pInternalMemory->groupMemory.Unmap();

        // Destroy the buddy allocator
        if (pInternalMemory->pBuddyAllocator != nullptr)
        {
            PAL_DELETE(pInternalMemory->pBuddyAllocator, m_pSysMemAllocator);
        }

        // Release this pool's base allocation
        FreeBaseGpuMem(pInternalMemory);

        // Remove this memory pool from the list if we added it
        if (needEraseFromOwnerList)
        {
            pOwnerList->Erase(&it);
        }
    }

Usage of interprocess BOs causes synchronization of GPU execution

Usage of interprocess BOs causes synchronization of GPU execution even if the usage happens on independent queues.

Currently all buffers created that don't have the "VM always valid" flag are added as memory references with all submissions. This causes the KMD to do implicit synchronization.

In order to allow efficient processing of data from multiple processes explicit synchronization in the applications must be used.

Windows compilation fails with unicode support

Compiling pal on Windows with unicode support enabled fails due to some Windows APIs used by gpuopen passing a regular string (LPCSTR) to functions that expect wide strings (LPCWSTR) when compiled with unicode support.

Communication through gpuopen can be unreliable for non-lan usage

Doing RGP captures or using other features through gpuopen protocols over UDP when connecting to cloud servers can be unreliable.

How to build on Windows use vs2019?

Hello, how to compile using vs2019 on windows? I used cmake to generate the vs2019 project and reported the following error:

CMake Error at cmake/PalVersionHelper.cmake:91 (message):
PAL_CLIENT_INTERFACE_MAJOR_VERSION not set. Defaulting to -1.
Call Stack (most recent call first):
cmake/PalBuildParameters.cmake:34 (pal_bp)
CMakeLists.txt:30 (include)

how will i deal with it?
thanks

Use of select() may exhaust available file descriptors

If an application uses the maximum number of file descriptors, using one more for select() will fail. Use poll() instead.

Allowing msvc compilation

pal won't allow msvc as compiler but dependency cwpack requires msvc, thus preventing compilation.

Is it possible to submit update patches individually rather than one giant patch includes many patches?

Is it possible to submit update patches individually rather than one giant patch includes many patches?

It is very hard to read added features when they are not isolated.

Swizzle questions

First, is this a good place for general questions about the PAL repo code?

On Gfx10, what is PipeBankXor exactly, and how important is it? I know it alters the swizzle pattern, but I'm wondering what would happen if I always used a ADDR2_COMPUTE_PIPEBANKXOR_INPUT::surfIndex of zero for example. Would parts of the hardware be underutilized? How much of a penalty might I be looking at?

For Gfx10Lib::HwlGetPreferredSurfaceSetting in the non-pow2 case, it looks like the swizzle precedence order for BC textures is D -> S -> R, and R -> D -> S for most other surfaces. What's the rationale there? How much worse might it be to use standard swizzle for BC textures when I could have used display?

HDR and all display modes > 8 bpc broken with current 2020-Q3-4 "release" again!

So i was just fetching and building the current state of the dev branch for the 2020-Q3-4 release to test how well it works. The depressing result is that it does not work at all in direct display mode for any swapchain format other than 8 bpc standard VK_FORMAT_B8G8R8A8_UNORM, ie. for VK_FORMAT_A2R10G10B10_UNORM_PACK32 etc.

Ofc. it doesn't matter so much, because whoever made the release also screwed up the release process, as no release announcement or actual packages for Ubuntu or RedHat were created :/.

Running an application using one of the higher precision formats leads to a hang in vkAcquireNextImageKHR() and game over.

The reason seems to be a missing modeset that seems to be required when switching framebuffer format.

The following diff, applied to the current pal/dev branch will fix the bug. It adds a ModeSet(pImage) call back into
DisplayWindowSystem::CreatePresentableImage, which was removed for the 2020-Q3-4 driver release.

I don't know if this is the current solution, because somebody thought that ModeSet to be not needed. But it should give you an idea what's wrong.

diff --git a/src/core/os/amdgpu/display/displayWindowSystem.cpp b/src/core/os/amdgpu/display/displayWindowSystem.cpp
index 9994acd..7b15b21 100644
--- a/src/core/os/amdgpu/display/displayWindowSystem.cpp
+++ b/src/core/os/amdgpu/display/displayWindowSystem.cpp
@@ -285,6 +285,7 @@ Result DisplayWindowSystem::CreatePresentableImage(
pImage->SetPresentImageHandle(imageHandle);

         FindCrtc();

•        ModeSet(pImage);
     }
  

  }

vkDestroySwapchain deadlocks on Xorg

On VK_KHR_xcb_surface, tearing down swapchain triggers a deadlock. FWIW, there's a similar bug in Mesa.

#0  0x00007ffff747ecd6 in do_futex_wait.constprop () from /usr/lib/libpthread.so.0
#1  0x00007ffff747edc8 in __new_sem_wait_slow.constprop.0 () from /usr/lib/libpthread.so.0
#2  0x00007fffe517b836 in Pal::SwapChain::WaitIdle() () from /usr/lib/amdvlk64.so
#3  0x00007fffe505f8d7 in vk::entry::vkDestroySwapchainKHR(VkDevice_T*, VkSwapchainKHR_T*, VkAllocationCallbacks const*) () from /usr/lib/amdvlk64.so
#4  0x0000555555605bfe in Vulkan::WSI::deinit_external (this=0x555556589058) at /home/maister/git/granite/vulkan/wsi/wsi.cpp:346
#5  0x0000555555605ef2 in Vulkan::WSI::~WSI (this=0x555556589058, __in_chrg=<optimized out>) at /home/maister/git/granite/vulkan/wsi/wsi.cpp:500
#6  0x00005555555caed9 in Granite::SceneViewerApplication::~SceneViewerApplication (this=0x555556589050, __in_chrg=<optimized out>)
    at /home/maister/git/granite/application/application.cpp:323
#7  0x00005555555aa8f7 in std::default_delete<Granite::Application>::operator() (this=<optimized out>, __ptr=0x555556589050)
    at /usr/include/c++/7.2.1/bits/unique_ptr.h:78
#8  std::unique_ptr<Granite::Application, std::default_delete<Granite::Application> >::~unique_ptr (this=<synthetic pointer>, __in_chrg=<optimized out>)
    at /usr/include/c++/7.2.1/bits/unique_ptr.h:268
#9  main (argc=<optimized out>, argv=<optimized out>) at /home/maister/git/granite/application/platforms/application_glfw.cpp:335

VK_KHR_wayland_surface wanted

Currently, the VK_KHR_xcb_surface implementation does not work on Wayland (although RADV does), triggering a segfault in vkCreateSwapchainKHR.

Like RADV, it would be great to have a wayland implementation as well, considering amdgpu-dri is being used by both.

CalcMaxLateAllocLimit() minor sgpr calculation bug

In gfx9GraphicsPipeline.cpp, under the CalcMaxLateAllocLimit() function, you have the following:

const uint32 vsNumSgpr = (numSgprs * 8);
const uint32 vsNumVgpr = (numVgprs * 4);

My understanding is that it should be this instead for gfx9:

const uint32 vsNumSgpr = (numSgprs * 16);

Actually I'm wondering if you have to do a +1 as well before multiplying. The code does check whether vsNumSgprs is > 0 or not later on, but then uses it like so:

const uint32 maxSgprVsWaves = (chipProps.gfx9.numPhysicalSgprs / vsNumSgpr) * simdPerSh;

... which, unless numPhysicalSgprs is 0-based as well, seems to suggest the +1 should be there ...

The presence of AMDVLK hogs DRM_NODE_PRIMARY even without the VK_KHR_display instance extension

The mere presence of the AMDVLK driver hogs DRM_NODE_PRIMARY even when VK_KHR_display is not enabled.

I spent way too long debugging why Gamescope was getting -EBUSY when trying to start with RADV.
It was because AMDVLK was installed and hogging DRM master for itself at instance creation time, when it should not be. We do not even use KHR_display.

It should only open a master node (DRM_NODE_PRIMARY) when a Vulkan device is created and the instance has the VK_KHR_display extension enabled.

https://github.com/GPUOpen-Drivers/pal/blob/dev/shared/devdriver/shared/ddGpuInfo/src/ddLinuxAmdGpuInfo.cpp#L217

UNORM Depth buffer precision reduced to 22 or 15 bits

Precision was reduced to 22 bits for 24 bit UNORM depth buffers and to 15 for 16 bit UNORM depth buffers in 6fa4f8a (see changes in src/core/hw/gfxip/gfx9/gfx9DepthStencilView.cpp or src/core/hw/gfxip/gfx6/gfx6DepthStencilView.cpp). The change was introduced to correct rounding issues when depth bias is 1.0f, but reduces image quality overall. A solution what fixes the rounding issue while maintaining precision would be ideal

Disable memset and change packet initialization order to optimize write combine

gfx9CmdUtil.cpp uses memset to set the pm4 packet structs to 0 and then fills individual fields of the packet. Using memset to set to zero and then initializing the struct impacts the write combine.

Question for UseMipInSrd

if useMipInSrd is true in rsrcProcMgr.cpp, then does selecting CopyImage2dShaderMipLevel pipeline look natural literally??

else if (useMipInSrd)
{
    // GFX10+: The types declared in the IL source are encoded into the DIM field of the instructions.
    //    DIM determines the max number of texture parameters [S,R,T,Q] to allocate.
    //    TA ignores unused parameters for a resource if the image view defines them as size 1.
    //    [S,R,T] can be generalized (3D, 2D array) for non-sampler operations like copies.
    //        [Q] TA's interpretation of Q depends on DIM. MIP unless DIM is MSAA
    //    Image Copies with a Q component need their own copy shaders.
    //    Simpler copies (non-msaa, non-mip) can all share a single 3-dimensional (2d array) copy shader.
    pipeline = RpmComputePipeline::CopyImage2d;
}
else
{
    pipeline = RpmComputePipeline::CopyImage2dShaderMipLevel;
}

Add zwp_linux_dmabuf_v1 support to Wayland WSI

I noticed that the Wayland WSI currently uses the old wl_drm. Most compositor implementations better support the newer zwp_linux_dmabuf_v1 protocol. wl_drm might not necessarily be available if the compositor uses Vulkan for rendering.

Unbounded memory usage increase with implicit command buffer reset

Sometimes when reusing command buffers with implicit command buffer resets through begin calls the memory usage keeps increasing. After running an application for hours this causes crashes due to out of memory issues. Adding either type of command buffer reset prevents the issue from happening.

The issue can be resolved by expanding the implicit reset code path in BeginCommandStream of GfxCmdBuffer to also reset the internal structures as seen in the Reset() function.

vkGetRandROutputDisplayEXT doesn't return VK_INCOMPLETE when it should

@ kleinerm report it on #37

Additionally there is a bug in the XGL component which prevents vkGetRandROutputDisplayEXT() from returning VK_INCOMPLETE as it should if it encounters this pal error.

Here:

https://github.com/GPUOpen-Drivers/xgl/blob/2c44bbc7b58efba12c501f71f5b268f83c1bdad5/icd/api/vk_physical_device.cpp#L3808

Inside the error handling clause of the if statement, instead of
result = VK_INCOMPLETE;
we have
VKResult result = VK_INCOMPLETE;

So in case of error, result is assigned inside the local scope, and then goes out of scope when leaving that branch, and return result actually returns VK_SUCCESS.

However, i actually stumbled over these bugs while i was trying to figure out why vkGetRandROutputDisplayEXT() works unreliably in the officially released amdvlk drivers.

Testing against the different released drivers on Ubuntu 19.10, depending on the driver release, either vkGetRandROutputDisplayEXT() works as expected, or fails and returns VK_SUCCESS, but also returns a NULL VkDisplayKHR handle. I'm not sure if this is because the driver is only officially supported for Ubuntu 18.04 LTS, or if something is wrong in your release process. I can't reproduce the failure with my own self-built driver checked out from your Git repos, so was unable to track down the cause.

E.g., these releases worked on Ubuntu 19.10:

amvlk PRO 1.1.129 from the amdgpu-pro driver package.
amdvlk 2019.Q4-3
And one of the 2020.Q1-x drivers also worked, can't remember which one atm.

These fail:

2019-Q4-5
2020-Q1-1

And the latest 2020-Q2-1 driver fails again.

build error with PAL_BUILD_GFX9=OFF

Build fails when setting -DPAL_BUILD_GFX9=OFF with:

/home/zenyd/Downloads/amdvlk/drivers/pal/src/core/device.cpp: In static member function ‘static bool Pal::Device::DetermineGpuIpLevels(Pal::uint32, Pal::uint32, Pal::uint32, Pal::HwIpLevels*)’:
/home/zenyd/Downloads/amdvlk/drivers/pal/src/core/device.cpp:176:10: error: ‘FAMILY_AI’ was not declared in this scope
     case FAMILY_AI:
          ^~~~~~~~~
/home/zenyd/Downloads/amdvlk/drivers/pal/src/core/device.cpp:176:10: note: suggested alternative: ‘FAMILY_CI’
     case FAMILY_AI:
          ^~~~~~~~~
          FAMILY_CI
make[2]: *** [pal/src/CMakeFiles/pal.dir/build.make:180: pal/src/CMakeFiles/pal.dir/core/device.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:17635: pal/src/CMakeFiles/pal.dir/all] Error 2

I think this is missing

+++ b/src/core/device.cpp
@@ -173,7 +173,9 @@ bool Device::DetermineGpuIpLevels(
         break;
 #endif
 #if PAL_BUILD_OSS4
+#if PAL_BUILD_GFX9
     case FAMILY_AI:
+#endif
     case FAMILY_RV:
         pIpLevels->oss = Oss4::DetermineIpLevel(familyId, eRevId);
         break;

because FAMILY_AI only gets defined when PAL_BUILD_GFX9=ON (see here)

Use of select() file descriptor can exceed FD_SETSIZE

The issue we ran into with select was that the file descriptor used in PAL was >= 1024 (FD_SETSIZE) which is the limit select fd_set will handle in glibc's implementation. Using poll doesn't have the same constraint and allows an application which already has many open file descriptors to work correctly with PAL.

vkCreate*Pipeline slows down for larger pipelines

vkCreate*Pipeline slows down when the size of the pipeline is bigger than 128KB. Pipelines large than 128KB cause a separate allocation of default pool size of 256KB. Also for each pipeline creation the pool gpumemory is mapped and unmapped.

This can be resolved by increasing the default size of the pool and keeping the memory mapped after usage. The mapped memory can be reused by the new vkCreate*Pipeline.

pal assumes the processor is an x86

Parts of pal use x86 specific headers and instructions (e.g. CpuId stuff in palSysUtil.h, sysUtil.cpp, lnxSysUtil.cpp).
AMD GPUs are used in other machines (aarch64, RISC-V) as well; works fine with Mesa drivers. AMDVLK currently can't be compiled for those machines.

Build failures with gcc

The dev checkout of AMDVLK fails to build with gcc. This was caught by the llpc/xgl CI in a newly opened PR GPUOpen-Drivers/xgl#109.

/usr/bin/g++ -DADDR_CI_BUILD -DADDR_GFX10_BUILD -DADDR_GFX9_BUILD -DADDR_NAVI12_BUILD -DADDR_NAVI14_BUILD -DADDR_NAVI21_BUILD -DADDR_NAVI22_BUILD -DADDR_RAVEN1_BUILD -DADDR_RAVEN2_BUILD -DADDR_RENOIR_BUILD -DADDR_SI_BUILD -DADDR_VEGA12_BUILD -DADDR_VEGA20_BUILD -DLITTLEENDIAN_CPU -D_DEBUG -I/vulkandriver/drivers/pal/src/core/imported/addrlib/inc -I/vulkandriver/drivers/pal/src/core/imported/addrlib/src -I/vulkandriver/drivers/pal/src/core/imported/addrlib/src/core -I/vulkandriver/drivers/pal/src/core/imported/addrlib/src/chip/r800 -I/vulkandriver/drivers/pal/src/core/imported/addrlib/src/chip/gfx9 -I/vulkandriver/drivers/pal/src/core/imported/addrlib/src/chip/gfx10 -O3  -fPIC   -UNDEBUG -flto -fuse-linker-plugin -Wno-odr -fPIC -Werror -fno-strict-aliasing -fno-exceptions -fno-rtti -fcheck-new -fno-math-errno -Wall -Wextra -Wno-unused -Wno-unused-parameter -Wno-unused-command-line-argument -Wno-ignored-qualifiers -Wno-missing-field-initializers -Wno-self-assign -Wno-implicit-fallthrough -std=c++11 -MD -MT pal/addrlib/CMakeFiles/addrlib.dir/src/gfx10/gfx10addrlib.cpp.o -MF pal/addrlib/CMakeFiles/addrlib.dir/src/gfx10/gfx10addrlib.cpp.o.d -o pal/addrlib/CMakeFiles/addrlib.dir/src/gfx10/gfx10addrlib.cpp.o -c /vulkandriver/drivers/pal/src/core/imported/addrlib/src/gfx10/gfx10addrlib.cpp
/vulkandriver/drivers/pal/src/core/imported/addrlib/src/gfx10/gfx10addrlib.cpp: In member function ‘virtual ADDR_E_RETURNCODE Addr::V2::Gfx10Lib::HwlGetPreferredSurfaceSetting(const ADDR2_GET_PREFERRED_SURF_SETTING_INPUT*, ADDR2_GET_PREFERRED_SURF_SETTING_OUTPUT*) const’:
/vulkandriver/drivers/pal/src/core/imported/addrlib/src/gfx10/gfx10addrlib.cpp:3110:80: error: enumeral and non-enumeral type in conditional expression [-Werror=extra]
 3110 |                             minSizeBlk = (minSizeBlk == AddrBlockMaxTiledType) ? AddrBlockLinear : minSizeBlk;
      |                                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/vulkandriver/drivers/pal/src/core/imported/addrlib/src/gfx10/gfx10addrlib.cpp: At top level:
cc1plus: error: unrecognized command line option ‘-Wno-self-assign’ [-Werror]
cc1plus: error: unrecognized command line option ‘-Wno-unused-command-line-argument’ [-Werror]
cc1plus: all warnings being treated as errors

I think this may come from the addrlib cmake file:

➜ /ssd/opensource/amdvlk/vulkandriver/drivers  
$ ag self-assign -Gtxt
spvgen/external/SPIRV-tools/CMakeLists.txt
92:    set(SPIRV_WARNINGS ${SPIRV_WARNINGS} -Wno-self-assign)

pal/src/core/imported/addrlib/CMakeLists.txt
223:        -Wno-self-assign

$ ag unused-command-line-argument -Gtxt
llvm-project/libcxx/benchmarks/CMakeLists.txt
11:    -Wno-unused-command-line-argument

llvm-project/libcxx/CMakeLists.txt
683:    target_add_compile_flags_if_supported(${target} PUBLIC -Wno-unused-command-line-argument)

llvm-project/flang/CMakeLists.txt
347:    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-unused-command-line-argument -Wstring-conversion \

llvm-project/compiler-rt/lib/tsan/CMakeLists.txt
116:if("${CMAKE_C_FLAGS}" MATCHES "-Wno-(error=)?unused-command-line-argument")
117:  set(EXTRA_CFLAGS "-Wno-error=unused-command-line-argument ${EXTRA_CFLAGS}")

llvm-project/libcxxabi/CMakeLists.txt
442:  add_compile_flags_if_supported(-Wno-unused-command-line-argument)

pal/src/core/imported/addrlib/CMakeLists.txt
220:        -Wno-unused-command-line-argument

pal/src/core/imported/vam/CMakeLists.txt
110:        -Wno-unused-command-line-argument

Possibly erroneous PAL_ASSERT

Hi,

When running AMDVLK driver on debug mode I get the following message:

AMD-PAL: Error: Assertion failed: pInfo->interpolatorCount >= 1 | Reason: Unknown (/some/path/drivers/pal/src/core/hw/gfxip/gfx6/gfx6PipelineChunkVsPs.cpp:124:EarlyInit)

I get this message on pipelines that are mainly used in shadowpasses. Those pipelines are not expected to have any varyings (I guess that's what you call interpolators). Maybe the assertion is incorrect.

Can Mantle be open sourced?

Can Mantle to PAL layer be open sourced?

Thanks!

PAL Code Object to D3D12 Pipeline State

Hello -- Not an issue, but a question. If I have a PAL compatible code object can is there an interface to create a ID3D12PipelineState object from it?

Thank You

• Justin

GCC 7.2 constexpr compilation issues

Hi,

I had some compilation issues while trying to compile this project on Fedora 27 :

/mnt/workspace/vulkandriver/drivers/pal/src/util/math.cpp:73:1: error: 'const Util::Math::NBitFloatInfo{16, 10, 5, 15, 32768, 1023, 31744, 15, 15, -14, 1199562752, 947912704, ((Util::uint32)((((1 << (5 - 1)) - 1) - 127) << 23)), 13}' is not a constant expression
};
^
/mnt/workspace/vulkandriver/drivers/pal/src/util/math.cpp:91:1: error: 'const Util::Math::NBitFloatInfo{11, 6, 5, 0, 0, 63, 1984, 15, 15, -14, 1191698432, 947912704, ((Util::uint32)((((1 << (5 - 1)) - 1) - 127) << 23)), 17}' is not a constant expression
};
^
/mnt/workspace/vulkandriver/drivers/pal/src/util/math.cpp:109:1: error: 'const Util::Math::NBitFloatInfo{10, 5, 5, 0, 0, 31, 992, 15, 15, -14, 1191690240, 947912704, ((Util::uint32)((((1 << (5 - 1)) - 1) - 127) << 23)), 18}' is not a constant expression
};

I compiled using the instructions provided in the main repository (https://github.com/GPUOpen-Drivers/AMDVLK).

Thanks

---

Compiler version :

c++ (GCC) 7.2.1 20170915 (Red Hat 7.2.1-2)
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

CMake version :

cmake version 3.10.0

CMake suite maintained and supported by Kitware (kitware.com/cmake).

Driver failed to create swapchain if modesetting driver is being used.

Any XCB/XLIB Vulkan application would fail to create swapchain if X is launched with mode setting driver but not amdgpu's ddx driver.

Shadowmap visual quality issues by a reduction of depth buffer precision

In commit 2483d46 the depth buffer precision was lowered which causes a reduced visual quality in scenes with shadow maps.

This change was done before but was reverted in 02e0b6b

You can refer to the conversation on the commit to know more details and the previous issue #49

Compilation error on PAL_ASSERT_MSG

On gcc 8.1.1 the current build in dev throws
AMDVLK/vulkandriver/drivers/pal/inc/util/palAssert.h:96:20: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]

In PAL_ASSERT_MSG()
changing if ((_expr) == false)

to either if (!(_expr)) or if ((_expr) == 0) should fix this

vkGetShaderInfoAMD fails to get disassembly on Linux

I tried using vkGetShaderInfoAMD to get a disassembly of a pipeline, but this apparently is not supported properly on AMDVLK. Is there any reason why this is supported on Windows, but not Linux?

UNORM Depth buffer precision reduced to 22 or 15 bits

Precision was reduced to 22 bits for 24 bit depth buffers and to 15 for 16 bit depth buffers in 6fa4f8a (see changes in src/core/hw/gfxip/gfx9/gfx9DepthStencilView.cpp or src/core/hw/gfxip/gfx6/gfx6DepthStencilView.cpp). The change was introduced to correct rounding issues when depth bias is 1.0f, but reduces image quality overall. A solution what fixes the rounding issue while maintaining precision would be ideal

Errors in lnxUuid.cpp fail the build of amdvlk-2022.Q3.2

Tried to make a package for openSUSE and got this for both gcc-12 and clang-14:

[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:68:8: error: variable has incomplete type 'tm'
[ 2332s]     tm FixedPoint = {0, 0, 0, 1, 2, 2021};
[ 2332s]        ^
[ 2332s] /usr/include/wchar.h:83:8: note: forward declaration of 'tm'
[ 2332s] struct tm;
[ 2332s]        ^
[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:80:47: error: use of undeclared identifier 'CLOCK_MONOTONIC'
[ 2332s]     bool clockGettimeSuccess = (clock_gettime(CLOCK_MONOTONIC, &time) == 0);
[ 2332s]                                               ^
[ 2332s] /home/abuild/rpmbuild/BUILD/amdvlk-2022.Q3.2/pal/src/util/lnx/lnxUuid.cpp:90:47: error: use of undeclared identifier 'CLOCK_REALTIME'
[ 2332s]     bool clockGettimeSuccess = (clock_gettime(CLOCK_REALTIME, &time) == 0);

wrong register used for SPI_SHADER_REQ_CTRL on gfx10

Just noticed this on navi, but for SHADER_REQ_CNTL for vertex shaders it's using the wrong thing

I'm sure you've fixed it internally already but for the lols.

diff --git a/src/core/hw/gfxip/gfx9/gfx9PipelineChunkVsPs.cpp b/src/core/hw/gfxip/gfx9/gfx9PipelineChunkVsPs.cpp
index cab8947..6837818 100644
--- a/src/core/hw/gfxip/gfx9/gfx9PipelineChunkVsPs.cpp
+++ b/src/core/hw/gfxip/gfx9/gfx9PipelineChunkVsPs.cpp
@@ -440,7 +440,7 @@ void PipelineChunkVsPs::LateInit(

         if (IsGfx10(chipProps.gfxLevel))
         {

•            pUploader->AddShReg(Gfx10::mmSPI_SHADER_REQ_CTRL_PS, m_commands.sh.vs.shaderReqCtrlVs);
  

•            pUploader->AddShReg(Gfx10::mmSPI_SHADER_REQ_CTRL_VS, m_commands.sh.vs.shaderReqCtrlVs);
         }
     } // if enableNgg == false
  

Support for Musl Libc (`seed48_r`, `mrandr48_r`)

ADMVLK mostly runs fine on Linux systems with Musl libc instead of Glibc, there are only two small occurring in pal, 1 #25 and otherwise the use the drandr48_r function family,
I already created a small patch, but I wanted to ask beforehand whether these functions should be added to this repo or if I should let pal link against them as an external library?

Precompiled Shader Sources

I’d like to package amdvlk (and thus pal) for a FSDG-compatible distribution with strict requirements to build everything from source (GNU Guix). However I see that

• https://github.com/GPUOpen-Drivers/pal/blob/master/inc/gpuUtil/textWriter/g_textWriterComputePipelineBinaries.h
• https://github.com/GPUOpen-Drivers/pal/blob/master/inc/gpuUtil/mlaa/g_mlaaComputePipelineBinaries.h
• https://github.com/GPUOpen-Drivers/pal/blob/master/inc/gpuUtil/timeGraph/g_timeGraphComputePipelineBinaries.h

contain pre-compiled shaders. Are they available somewhere in source code form?

PAL code violates One Definition Rule during link phase.

When building with gcc 7.2.1, I get the following warnings at the end of the build as it's linking amdvlk64.so:

/home/clee/src/vulkandriver/drivers/pal/inc/core/palLib.h:90:12: note: type ‘NullGpuId’ itself violates the C++ One Definition Rule
enum class NullGpuId : uint32
^
/home/clee/src/vulkandriver/drivers/pal/inc/core/palLib.h:90:12: note: type ‘NullGpuId’ itself violates the C++ One Definition Rule
/home/clee/src/vulkandriver/drivers/pal/inc/core/palDevice.h:155:12: note: type ‘AsicRevision’ itself violates the C++ One Definition Rule
enum class AsicRevision : uint32
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95400:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:56816:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:34950:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:22985:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:81606:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:46883:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:10568:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:6147:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:94865:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:56258:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:11922:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:7712:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:4271:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:1696:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:10721:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:6351:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:10672:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:6289:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:10652:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:6270:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:20563:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:14367:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:20026:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:13726:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95291:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:56696:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:80869:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:46146:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:20597:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:14430:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82188:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47531:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82034:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47417:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82208:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47552:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82044:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47426:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82129:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47489:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:81994:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47381:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82024:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47408:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:82149:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:47510:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95827:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:57227:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:5319:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:3003:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95947:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:57370:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95132:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:56539:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:95687:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:57083:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:28072:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:16415:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:80110:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:45334:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx6/chip/si_ci_vi_merged_registers.h:60266:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/gfxip/gfx9/chip/gfx9_plus_merged_registers.h:33331:9: note: the incompatible type is defined here
struct {
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss2/sdma20_pkt_struct.h:735:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss4/sdma40_pkt_struct.h:917:9: note: the incompatible type is defined here
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss2/sdma20_pkt_struct.h:733:5: note: type ‘union ’ itself violates the C++ One Definition Rule
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss4/sdma40_pkt_struct.h:915:5: note: the incompatible type is defined here
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss2/sdma20_pkt_struct.h:930:9: note: type ‘struct ’ itself violates the C++ One Definition Rule
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss4/sdma40_pkt_struct.h:1100:9: note: the incompatible type is defined here
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss2/sdma20_pkt_struct.h:928:5: note: type ‘union ’ itself violates the C++ One Definition Rule
{
^
/home/clee/src/vulkandriver/drivers/pal/src/core/hw/ossip/oss4/sdma40_pkt_struct.h:1098:5: note: the incompatible type is defined here
{
^
/home/clee/src/vulkandriver/drivers/pal/inc/core/palDevice.h:569:8: note: type ‘struct DeviceProperties’ itself violates the C++ One Definition Rule
struct DeviceProperties
^

GCC 7.2 lnxGpuMemory.cpp:134:17 compile error: ISO C++ forbids comparison between pointer and integer

/home/constantine/AMDVLK/pal/inc/util/palAssert.h:96:20: error: ISO C++ forbids comparison between pointer and integer [-fpermissive]
     if ((_expr) == false)                                                                         \
                    ^
/home/constantine/AMDVLK/pal/inc/util/palAssert.h:104:27: note: in expansion of macro ‘PAL_ASSERT_MSG’
 #define PAL_ASSERT(_expr) PAL_ASSERT_MSG(_expr, "%s", "Unknown")
                           ^~~~~~~~~~~~~~
/home/constantine/AMDVLK/pal/src/core/os/lnx/lnxGpuMemory.cpp:134:17: note: in expansion of macro ‘PAL_ASSERT’
                 PAL_ASSERT(m_pPinnedMemory);
                 ^~~~~~~~~~
make[2]: *** [pal/src/CMakeFiles/pal.dir/core/os/lnx/lnxGpuMemory.cpp.o] Error 1
make[1]: *** [pal/src/CMakeFiles/pal.dir/all] Error 2
make: *** [all] Error 2

constantine@linux:~/AMDVLK$ gcc --version
gcc (Ubuntu 7.2.0-18ubuntu2) 7.2.0