omegatron has quit [Quit: What happened? You quit!]
<hch12907>
zmike: i've found meson-without-docs magnitudes better than cmake-without-docs (sometimes even cmake-with-docs)
<hch12907>
cmake is just that terrible
<hch12907>
kusma: could the problem be that we are not enabling the extensions, while at the same time passing in the extension feats?
<hch12907>
or maybe we have enabled a faulty feature...
<kusma>
hch12907: I tried stripping down what we pass to vkCreateDevice until it works, and it seems passing *any* of the extension-structs we would cause the driver to go belly-up
<kusma>
wait a minute... I messed that up, hold on.
<kusma>
Seems EXT_robustness2 is the culprit
<hch12907>
I don't think passing extension structs can create any problem, since they extend VkDeviceCreateInfo
<kusma>
Well, it does :P
<hch12907>
:(
<kusma>
I wonder if we're enabling more than we want from that extension...
<kusma>
I think all we really want is the nullDescriptors features... I wonder if we need to respect the alignment stuff from the properties if we want to enable the other two features...?
<hch12907>
we enable every extension feature the driver advertises
<kusma>
Yeah disabling the robustBufferAccess2-feature alone is enough.
<hch12907>
huh, sounds like a driver bug
<kusma>
I think I need to read the spec before I make that call :P
<hch12907>
it wouldn't be too hard to change the codegen, so that it enables only the extension features we want
<kusma>
I actually wonder if we're reading outside of the defined size of our UBOs or something like that...
<hch12907>
shouldn't robustBufferAccess2 take care of that?
<kusma>
Oh, this is really easy to monkey-patch away; I can just set the flag to false right before we create the device
omegatron has joined #zink
<kusma>
hch12907: Well, yeah. But there's some alignment stuff that is needed to get that guarantee.
<hch12907>
"must be bounds-checked to the range of the descriptor", right... I missed that. Oops!
<kusma>
Seems robustStorageBufferAccessSizeAlignment is 4 on both intel windows and intel linux...
<kusma>
but robustUniformBufferAccessSizeAlignment is 4 on Windows and 64 on Linux, which could let some stuff fall through the cracks...
<kusma>
But it's also 4 on RADV, so we probably should have seen issues related to that already...
<zmike>
I'd been meaning to disable robust buffer access for a while
<zmike>
I don't think it's a requirement for compat
<zmike>
unless a robust context is requested
<zmike>
ah now that I actually look at it I don't think that's viable
<hch12907>
robustBufferAccess2 is never needed, is it
<zmike>
yes
<hch12907>
the only condition for robustness2 has been nullDescriptor since forever
<zmike>
technically it's needed to preserve behavior for invalid access of texel buffers
hch12907 has quit [Remote host closed the connection]
hch12907 has joined #zink
<hch12907>
kusma: can you share your build options for mesa on Windows? I get some complains from meson, about missing dependencies libclc and spirv-tools
<hch12907>
which I think shouldn't be possible... considering that I am building only llvmpipe and zink
<kusma>
We don't need llvm and libclc
<kusma>
Just do `-Dllvm=false`
<kusma>
I'm disabling all other drivers than zink to avoid something pulling in a missing dependency
<kusma>
You really want to make sure that zlib thingie being static, otherwise you need to also copy the zlib dll around together with opengl32.dll, that's annoying ;)
<hch12907>
oh hey, it finally worked
<kusma>
Great :)
<hch12907>
building on Windows has always been a struggle for me (for projects not already using vcprojx) :/
<kusma>
I set up a new Windows dev machine recently, and I actually think things are becoming pretty nice. Finally fully embraced PowerShell instead of MSYS2 etc.
<kusma>
And with WSLg, I can now run Linux Desktop applications, which is pretty dope, and fixes a bunch of tiny pain-points for me.
<hch12907>
you still have to use MSYS2 to install stuff like GCC, don't you?
<kusma>
I don't use GCC :)
<hch12907>
I haven't really caught up to the recent developments in the Windows world
<kusma>
...On Windows anyway :)
<hch12907>
something about WSL, that's all I know. :P
<kusma>
Windows Terminal, PowerShell, WSL2, VS2019 it all goes together quite nicely.
<kusma>
* Windows Terminal, PowerShell, WSL2, VS2019... it all goes together quite nicely.
<kusma>
The most annoying detail ATM is that I'm currently using like 3 package managers
<kusma>
WinGet, Choco and Pip ;)
<kusma>
That's at least one too many IMO, but whatever
<hch12907>
right now all I use is MSYS2
<kusma>
That's fine for a MinGW setup
<kusma>
Oh, also... recent Windows has OpenSSH, so you can ssh in from a Linux machine and build :)
<kusma>
(setup is a bit hairy, but it works)
<hch12907>
OpenSSH? I have some bad flashbacks to last time I tried to build hyper-rs
<hch12907>
on Windows
<kusma>
No need to build anything, it's a Windows component now :)
<hch12907>
that's good, one less pain point to worry about!
<zmike>
hm I still remember the struggle to get something running in x11 on cygwin
<hch12907>
uhh, I dropped opengl32.dll into my gl-demos directory, and glxgears is apparently pumping 5000 frames per sec? doesn't sound right
<hch12907>
yeah, definitely not right... deleted opengl32.dll and still got around the same perf
<kusma>
You mean wglgears?
<kusma>
You can pass -info to them to see the renderer string etc
<hch12907>
Finally got zink to run on wglgears, aaaand it's a black screen
<zmike>
is black screen wglgears the new glxgears? 🤔
<hch12907>
but hey, it's running at 1000FPS!
<hch12907>
much better than softpipe
<zmike>
daniels: a new golden age of glxgears for benchmarking
<hch12907>
tried out some random demos; it clears the background colour properly, but no triangles are rendered