This bug appears to have been reported against 'rawhide' during the Fedora Linux 39 development cycle.
Changing version to 39.

At XDC2023 (oct), Faith Ekstrand and Karol Herbst gave a talk on upcoming NVK landing. 
Karol said, for Kepler series cards to work, a FLAG, NVK_I_WANT_A_BROKEN_NVK_DRIVER , needs to be enabled . [3]

I hope Karol intended it as a joke/discalimer/warning. In my searches in mesa gitlab code repo [4],[5], I could not find such flag. 
I hope this is not a compile time flag, but if it is this needs to be taken into consideration for fedora users with Kepler cards.
 

[1] 20231019 - Phoronix/Mesa/Michael Larabel - Even Though It's Currently Slow, The Mesa NVIDIA "NVK" Vulkan Driver Has Been Making Good Progress
    https://www.phoronix.com/news/NVK-Vulkan-XDC-2023
[2] 202310 - XDC2023 (oct), Faith Ekstrand and Karol Herbst - Nouveau/NVK Update (start of the talk)
    https://www.youtube.com/watch?v=Gg4eSAP1uc4&t=5589s 
[3] same as above, time offset to section "NVK merged into mesa" (part where Kepler is mentioned)
    https://www.youtube.com/watch?v=Gg4eSAP1uc4&t=6338 
[4] mesa gitlab search for flag
    https://gitlab.freedesktop.org/search?group_id=1155&repository_ref=main&scope=projects&search=NVK_I_WANT_A_BROKEN_NVK_DRIVER 
[5] mesa gitlab file for nvk device enumeration
    https://gitlab.freedesktop.org/mesa/mesa/-/blob/c68b4e4b3a84cb023d6356a7989ebae78c3b1092/src/nouveau/vulkan/nvk_physical_device.c

Typo : in prev comment, my bad, it was Faith (not Karol) doing the talking at the referenced-time in the video.

I think the initial solution is to not ship NVK in distro packages until we drop the `-experimental` from the configure flag. Until then, it's probably best to not ship it be default. If someone wants to make a copr, go for it!

Created attachment 1996561 [details]
vulkaninfo_before_6.5.6

vulkan info before upgrading mesa, kernel

Created attachment 1996574 [details]
vulkaninfo_after_6.6.0

vulkaninfo after upgrading mesa and kernel

@jexposit has already made the fedora mesa-23.3 srpm
@jexposit also supplied me some srpm building tips, which enabled me to compile and install the required 23.3 rpms. Thx to that
https://koji.fedoraproject.org/koji/packageinfo?packageID=184
I downloaded a new mesa-src-tar ball, applied the patch in the merge request, created a new SOURCES/mesa-23.3.0-rc1.tar.xz

@jforbes has already built kernel-6.6.0 x8_64 rpms
https://koji.fedoraproject.org/koji/packageinfo?packageID=8 
on kernel-6.5.6, vulkaninfo bails out with warning and a message to use kernel-6.6. 

linux already upgraded to fedora-39
root@sirius:~/rpmbuild/SPECS$ cat /etc/os-release | grep -E ^VERSION=
VERSION="39 (Workstation Edition)"
root@sirius:~# uname -a
Linux sirius 6.6.0-61.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Oct 30 12:32:17 UTC 2023 x86_64 GNU/Linux

vulkaninfo is detecting the NVIDIA graphics as GPU1 (0=intel, 2=cpu)
vulkan_info logs both before and after have been attached. (see prev comments) 

GPU0:
VkPhysicalDeviceProperties:
---------------------------
        apiVersion        = 1.2.267 (4202763)
        driverVersion     = 23.3.0 (96481280)
        vendorID          = 0x8086 
        deviceID          = 0x0416
        deviceType        = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
        deviceName        = Intel(R) HD Graphics 4600 (HSW GT2)
        pipelineCacheUUID = d5ad8d8e-a04d-8a25-46c6-32ab8de20e0d
GPU1:
VkPhysicalDeviceProperties:
---------------------------
        apiVersion        = 1.0.267 (4194571)
        driverVersion     = 23.3.0 (96481280)
        vendorID          = 0x10de 
        deviceID          = 0x1292
        deviceType        = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU  
        deviceName        = GeForce GT 740M
        pipelineCacheUUID = 686d2015-72ef-da16-2913-9d6e29a772d4
GPU2:
VkPhysicalDeviceProperties:
---------------------------
        apiVersion        = 1.3.267 (4206859)
        driverVersion     = 0.0.1 (1)
        vendorID          = 0x10005
        deviceID          = 0x0000
        deviceType        = PHYSICAL_DEVICE_TYPE_CPU           
        deviceName        = llvmpipe (LLVM 17.0.1, 256 bits)
        pipelineCacheUUID = 32332e33-2e30-2d72-6331-616161616161


root@sirius:~/tmp/qq# rpm -qil mesa-vulkan-drivers | grep nouveau 
/usr/lib64/libvulkan_nouveau.so
/usr/share/vulkan/icd.d/nouveau_icd.x86_64.json

gana@sirius:~/rpmbuild/SPECS$ rpm -qa | egrep -i "^mesa" | sort
mesa-dri-drivers-23.2.1-2.fc39.i686
mesa-dri-drivers-23.3.0~rc1-1.fc39.x86_64
mesa-filesystem-23.2.1-2.fc39.i686
mesa-filesystem-23.3.0~rc1-1.fc39.x86_64
mesa-libEGL-23.2.1-2.fc39.i686
mesa-libEGL-23.3.0~rc1-1.fc39.x86_64
mesa-libgbm-23.2.1-2.fc39.i686
mesa-libgbm-23.3.0~rc1-1.fc39.x86_64
mesa-libGL-23.2.1-2.fc39.i686
mesa-libGL-23.3.0~rc1-1.fc39.x86_64
mesa-libglapi-23.2.1-2.fc39.i686
mesa-libglapi-23.3.0~rc1-1.fc39.x86_64
mesa-libGLU-9.0.3-1.fc39.x86_64
mesa-libOpenCL-23.3.0~rc1-1.fc39.x86_64
mesa-libOSMesa-23.2.1-2.fc39.i686
mesa-libOSMesa-23.3.0~rc1-1.fc39.x86_64
mesa-libxatracker-23.3.0~rc1-1.fc39.x86_64
mesa-va-drivers-23.2.1-2.fc39.i686
mesa-va-drivers-23.3.0~rc1-1.fc39.x86_64
mesa-vdpau-drivers-23.3.0~rc1-1.fc39.x86_64
mesa-vulkan-drivers-23.2.1-2.fc39.i686
mesa-vulkan-drivers-23.3.0~rc1-1.fc39.x86_64

In the 30 min since the machine is booted, desktop gui has been up and seen gentle use, so far system seems stable. 

gana@sirius:~/rpmbuild/SPECS$ dmesg | grep -Ei "nouv|NVID|GK208"
[    3.399865] nouveau: detected PR support, will not use DSM
[    3.399893] nouveau 0000:01:00.0: enabling device (0006 -> 0007)
[    3.400062] nouveau 0000:01:00.0: NVIDIA GK208 (108120a1)
[    3.421429] nouveau 0000:01:00.0: bios: version 80.28.3e.00.1d
[    3.485768] nouveau 0000:01:00.0: fb: 2048 MiB DDR3
[    3.550731] nouveau 0000:01:00.0: DRM: VRAM: 2048 MiB
[    3.550735] nouveau 0000:01:00.0: DRM: GART: 1048576 MiB
[    3.550738] nouveau 0000:01:00.0: DRM: Pointer to TMDS table not found
[    3.550739] nouveau 0000:01:00.0: DRM: DCB version 4.0
[    3.551926] nouveau 0000:01:00.0: DRM: MM: using COPY for buffer copies
[    3.552206] [drm] Initialized nouveau 1.4.0 20120801 for 0000:01:00.0 on minor 1
[    3.552311] nouveau 0000:01:00.0: [drm] No compatible format found
[    3.552314] nouveau 0000:01:00.0: [drm] Cannot find any crtc or sizes
[   18.602532] nouveau 0000:01:00.0: Enabling HDA controller
[  109.317552] nouveau 0000:01:00.0: Enabling HDA controller


ok, so are there any test suites I can run, that can help Faith and Karol.

related informative discussion in bug report  
https://bugzilla.redhat.com/show_bug.cgi?id=2246233

Diff between the SRPM spec files to build nvk

gana@sirius:~/rpmbuild/SPECS$ diff mesa.spec 20231027_mesa.spec.orig 
21c21
< %global base_vulkan ,amd,nouveau-experimental
---
> %global base_vulkan ,amd
604d603
< %{_libdir}/dri/hdlcd_dri.so
661,662d659
< %{_libdir}/libvulkan_nouveau.so
< %{_datadir}/vulkan/icd.d/nouveau_icd*.json

I run NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vkcube --gpu_number 1
but I get only a grey window box, that I can only close. 

gana@sirius:~/rpmbuild/SPECS1$ vkcube
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 0: Intel(R) HD Graphics 4600 (HSW GT2), type: IntegratedGpu

gana@sirius:~/rpmbuild/SPECS$ vkcube --gpu_number 0
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 0: Intel(R) HD Graphics 4600 (HSW GT2), type: IntegratedGpu

gana@sirius:~/rpmbuild/SPECS$ vkcube --gpu_number 2
MESA-INTEL: warning: Haswell Vulkan support is incomplete
GPU 2 specified is not present, GPU count = 2
Specified GPU number is not present

gana@sirius:~/rpmbuild/SPECS1$ vkcube --gpu_number 1
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 1: llvmpipe (LLVM 17.0.1, 256 bits), type: Cpu

gana@sirius:~/rpmbuild/SPECS$ NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1 vkcube --gpu_number 1
WARNING: NVK is not a conformant Vulkan implementation, testing use only.
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 1: GeForce GT 740M, type: DiscreteGpu

--- 

fyi, the merge commit referred to in earlier comment  
that needed to be applied to the mesa-src tar ball that was  
mentioned in https://bugzilla.redhat.com/show_bug.cgi?id=2246233    
https://gitlab.freedesktop.org/mesa/mesa/-/issues/9791   
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25536  
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25536/diffs?commit_id=cb75f652610ff6fb309270e91f33af18f11dd8fb

vkcube update

summary: the vkcube sometimes works on GPU1=NVidia, some window sizes can cause the cube to be invisible. 

The vkcube window at the start seems like nothing is happening and is plain dark grey.
In the following, by resize window I mean drags the corner/side of the window with touchpad.
While resizing quickly (normal use speed), the rotating box can be seen strobo-scopically,  
If window size is resized and released in a lucky size, the rotating box will be visible.
It is possible to resize the window slowly, a few pixel movements at a time to find the visible state. 
Texture and color of the cube when visible is normal.
After finding a use-able window size, maximizing window does not preserve the luck, and in the maximized window the cube goes back to invisible cube with grey bg.
So the visibility of the cube is window-size dependent.   
These choices of usable window size are like a checkered pattern, where the cube is visible some squares and nor in others.
Same effect happens in horz-resize, vert-resize, corner-resize. 
Moving the window on the screen has no effect.
Alt-tabbing behind and in front of firefox has no effect.
Hoovering mouse over the vkcube window has no effect. 
resizing vkcube using GPU0 is fine. 

I did this start vkcube test repeatedly.
There were some runs, where VKcube for GPU1 shows the cube right away. 
when so, resizing causes the same effect and the cube can become invisible in some bands.  

Is it some kind of simple bug  / is it already known?
The bug might also something to do with canvas size, timing and copying rendered image to final display.  

experiment to make cube as large as possible on my 1920x1080 display:  
First I find a largest window max resize size for GPU1(NVK), which is what one gets when he height of window is same as height of screen.
On the smoothness, in both small window and largest window, not much noticable difference between GPU0 and GPU1, both smooth and at constant steady rate. 
Increase in size does not slow either one.  
In contrast llvmpipe, CPU(GPU2) seems to spin too quickly, like its jumping between frames. 
When the windows size is max sized, can't be sure, but perhaps it slows a little down

I'm not at all surprised that you're having issues on a GT 740M. That's a Kepler GPU which is the earliest we're even considering supporting and which basically hasn't gotten any testing whatsoever by developers.  The earliest GPU I've actually plugged into my box is a 750 TI which is an early Maxwell part and even those aren't the most stable yet.  It's hidden behind NVK_I_WANT_A_BROKEN_VULKAN_DRIVER for a reason.

Here in signing up. Happy to help with any testing. 
If there are 
  any "make test", I can run in the mesa mock build directory ? 
  any test suites you would want me to download, run, collect results, upload? 
pls do let me know. 

In case some need in the future requires some testing, you have me, and can just ping me over here to do any testing. 
The issue list also has my handle address. 

yeah, I'm afraid of Kepler not keeping up, and it shouldn't be for want of a tester. 
Its still a very good usable machine, good enough card and I'm sure there are lot of kepler users out there.  

But thanks a lot to yours and Karol's work on nvk and rusticl. 
I read about both of you on phoronix,  watched quite a few of your conference presentations, and sometimes try read the mesa issue chatter, though I don't understand them.

I just remembered to check ```dmesg -w``` when the cube is invisible. 
This is what i found

When the cube does show, dmesg is silent. which is good.

When the cube doesn't show, dmesg logs this (repeated endlessly): 
[14529.441484] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14529.441493] nouveau 0000:01:00.0: gr: SHADER a204021e, sph: 0x04021e, stage: 0x22
[14529.457362] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14529.457370] nouveau 0000:01:00.0: gr: SHADER a204021e, sph: 0x04021e, stage: 0x22
[14529.476161] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14529.476169] nouveau 0000:01:00.0: gr: SHADER a204021e, sph: 0x04021e, stage: 0x22


During the window resize, there some a few other types of logged error that happen repetitively for short durations
that are interspersed with the previous type.
The state changes are influenced by the resize events.
set1
:
[ 4767.776778] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[10147]]
[ 4767.776791] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3c0008 [MISALIGNED_REG]
[ 4767.776798] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3c0008 [MISALIGNED_REG]
[ 4767.793445] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[10147]]
[ 4767.793458] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3e0008 [MISALIGNED_REG]
[ 4767.793465] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3e0008 [MISALIGNED_REG]
:
set2
:
[14527.625201] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14527.625216] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3d0009 [ILLEGAL_INSTR_ENCODING]
[14527.625222] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3d0009 [ILLEGAL_INSTR_ENCODING]
[14527.642087] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14527.642110] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3f0009 [ILLEGAL_INSTR_ENCODING]
[14527.642116] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3f0009 [ILLEGAL_INSTR_ENCODING]
:
set3
:
[14525.323308] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14525.323321] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000000 [] warp 3d0009 [ILLEGAL_INSTR_ENCODING]
[14525.323327] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000000 [] warp 3d0009 [ILLEGAL_INSTR_ENCODING]
[14525.324295] nouveau 0000:01:00.0: gr: TRAP ch 2 [007fb44000 vkcube[22244]]
[14525.324304] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000000 [] warp 3f0009 [ILLEGAL_INSTR_ENCODING]
[14525.324310] nouveau 0000:01:00.0: gr: GPC0/TPC1/MP trap: global 00000000 [] warp 3f0009 [ILLEGAL_INSTR_ENCODING]
:

> Here in signing up. Happy to help with any testing. 

The problem isn't really needing someone to run the tests.  I've got a Kepler card in my pile that I can plug into my box easily enough.  It's more that there are a lot of moving pieces and debugging all the kepler fails hasn't moved to the top of the todo list yet.  That doesn't mean it never will, though.  The new compiler is working pretty well on Turing and people are working on porting it to Maxwell.  Next comes Kepler at which point someone will need to do that work.  Kepler is making its way up the list, if slowly.

What would help more is if someone with a kepler card wanted to join in on the development efforts.  There's probably a lot of low-hanging fruit.  I haven't actually done any triage on Kepler yet, though, so I can't exactly suggest a starting point besides "run dEQP, see what fails, and try to fix it."

> [ 4767.776791] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3c0008 [MISALIGNED_REG]

> [14527.625216] nouveau 0000:01:00.0: gr: GPC0/TPC0/MP trap: global 00000004 [MULTIPLE_WARP_ERRORS] warp 3d0009 [ILLEGAL_INSTR_ENCODING]

Hrm...  If I had to take a guess, I'd say something is going wrong with shader upload, instruction pre-fetch, or instruction caching.  Typically, that sort of error means there's something wrong with the compiler bug vkcube has pretty simple shaders and they're clearly working most of the time.  If it's happening on resize, it's more likely that something is going OOB and stomping shaders or that something is wrong with the shader heap itself.

@hgkamath now that the issues with LLVM 17 have been fixed:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25536

I plan to build mesa-23.3.0-rc2 + that patch today or tomorrow.


@hgkamath I'm also working on the Vulkan SDK (v1.3.268.0) on a side-tag. I also plan to push it to Rawhide today or tomorrow.

I pushed mesa-23.3.0-rc2 to rawhide.


The Vulkan SDK might get delayed because a new package is required:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2247640

For those watching the Kepler discussion, I've got a bunch of fixes here:

https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26035

I'm running the CTS now but early results say that gets rid of most of the disaster on Kepler.  It's still nowhere near ready to ship but I would guess vkcube works now.

First, the good news, vkcube works beautifully, no dmesg logs.
I added the kepler patch mentioned to the srpm and rebuilt mesa-23.3.0-rc3

I should have posted this sooner, but I have been trying to compile and run the vulkan CTS.

For sake of reader, here-in including the diff of srpm spec file. 
The patch file can be downloaded from gitlab merge request using the code button. 
gana@sirius:~/rpmbuild/SPECS$ diff mesa.spec  20231109_mesa.spec.orig 
21c21
< %global base_vulkan ,amd,nouveau-experimental
---
> %global base_vulkan ,amd
89d88
< Patch13:        0002-nvk-kepler-fixes-mr26035.patch
664,665d662
< %{_libdir}/libvulkan_nouveau.so
< %{_datadir}/vulkan/icd.d/nouveau_icd*.json

José, Thanks for the update, I normally track koji builds directly, especially some important packages, for which I even know the koji package no 8,184,3685,22087 . 
That's how I discovered that you attempted a mesa-23.0 build and then found your corresponding bug-report. 
Probably for a long time to come, until nvk stops being experimental, maybe I'll need to build mesa on my own. So, I'd be putting a exclude=mesa in my dnf.conf and mock build an srpm from time to time. So no need to trouble yourself to relay koji build updates.  

vulkan-tools-1.3.268.0-1.fc40.src.rpm, did not mock build on fc39, it probably needs vulkan-loader 
The mock build stop with error like
cmake: "target "vkcube" links to:     Vulkan::Loader" "  but the target was not found"
not yet bold enough to install vulkan-tools vulkan-loader, as I suspect there could be tighter dependencies.
gana@sirius:~/tmp/vcts/bd$ rpm -qa | grep vulkan
vulkan-loader-1.3.250.0-2.fc39.x86_64
vulkan-tools-1.3.250.0-2.fc39.x86_64
vulkan-loader-1.3.250.0-2.fc39.i686
mesa-vulkan-drivers-23.2.1-2.fc39.i686
mesa-vulkan-drivers-23.3.0~rc2-2.fc39.x86_64


I managed to compile deqp-vk, but still not figured out how to get it to run
gana@sirius:~/tmp/vcts/bd137$ NVK_I_WANT_A_BROKEN_VULKAN_DRIVER=1  ./external/vulkancts/modules/vulkan/deqp-vk --deqp-vk-device-id=1
Writing test log into TestResults.qpa
dEQP Core vulkan-cts-1.3.7.1-127-gb127977ddad4ea94393e519ad2368fe929cac922 (0xb127977d) starting..
  target implementation = 'Default'
FATAL ERROR: Vulkan is not supported at tcuPlatform.cpp:54
Killed
Also, How do i make it test only upto vulkan-1.0 or vulkan-1.1 ?

That error likely means you didn't build the Vulkan CTS properly.  Did you run external/fetch_sources.py?  If you don't, it won't work properly because it'll be missing a bunch of deps.

> vulkan-tools-1.3.268.0-1.fc40.src.rpm, did not mock build on fc39, it probably needs vulkan-loader 

@hgkamath you'd need to build other dependencies first.

I'm building the Vulkan SDK v1.3.268.0 in a side tag. However, some code previously present in vulkan-validation-layers was moved to a different repo upstream: vulkan-utility-libraries (https://github.com/KhronosGroup/Vulkan-Utility-Libraries)

I started the process to get this new package in Fedora (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2247640) but I'm still waiting for someone to review it. Help getting the package accepted is really welcome :D 

In case you are interested in the RPMs, most of the SDK is built in my side tag:

vulkan-headers: https://koji.fedoraproject.org/koji/taskinfo?taskID=108323591
spirv-headers: https://koji.fedoraproject.org/koji/taskinfo?taskID=108324675
vulkan-loader: https://koji.fedoraproject.org/koji/taskinfo?taskID=108326552
spirv-tools: https://koji.fedoraproject.org/koji/taskinfo?taskID=108325946
glslang: https://koji.fedoraproject.org/koji/taskinfo?taskID=108455332
shaderc: https://koji.fedoraproject.org/koji/taskinfo?taskID=108507549
vulka-tools: https://koji.fedoraproject.org/koji/taskinfo?taskID=108472079

Only vulkan-validation-layers, due to new dependency, is missing.

This message is a reminder that Fedora Linux 39 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 39 on 2024-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '39'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 39 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Fedora Linux 39 entered end-of-life (EOL) status on 2024-11-26.

Fedora Linux 39 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days

- sorry for late reply
- on laptop HP envy 17t-j186nr
- on Fedora-43 beta 
- on kernel 6.17.0-0.rc7.56.fc43.x86_64
- on DGPU Nvidia kepler GT740m with cpu Intel haswell i7-4700MQ with HD graphics 4600 iGPU
- vkcube seems to work
- vulkaninfo attached 

gana@sirius:~$ vkcube --gpu_number 0
Selected WSI platform: wayland
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 0: Intel(R) HD Graphics 4600 (HSW GT2), type: IntegratedGpu

gana@sirius:~$ vkcube --gpu_number 1
Selected WSI platform: wayland
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 1: GeForce GT 740M (NVK GK208), type: DiscreteGpu

gana@sirius:~$ vkcube --gpu_number 2
Selected WSI platform: wayland
MESA-INTEL: warning: Haswell Vulkan support is incomplete
Selected GPU 2: llvmpipe (LLVM 21.1.1, 256 bits), type: Cpu

gana@sirius:~$ rpm -qa | sort  | grep -Ei "mesa-vulkan-drivers.*x86_64|mesa-filesystem.*x86_64|gnome-shell-4|libwayland-server.*x86_64|vulkan-tools"
gnome-shell-49.0-1.fc43.x86_64
libwayland-server-1.24.0-1.fc43.x86_64
mesa-filesystem-25.2.3-2.fc43.x86_64
mesa-vulkan-drivers-25.2.3-2.fc43.x86_64
vulkan-tools-1.4.321.0-4.fc43.x86_64

Created attachment 2108135 [details]
vulkaninfo-6.17.0-0.rc7.56.fc43