hch12907 has quit [Remote host closed the connection]
hch12907 has joined #zink
<airlied>
../src/gallium/drivers/zink/zink_program.c:444:67: warning: result of comparison of constant -1 with expression of type 'unsigned char' is always false [-Wtautological-constant-out-of-range-compare] if (ctx->curr_program->shader_slot_map[slot] == -1)
<airlied>
./src/gallium/drivers/zink/zink_context.c:3280:14: warning: taking the absolute value of unsigned type 'unsigned int' has no effect [-Wabsolute-value] last = abs(reads - writes) > UINT32_MAX / 2 ? MIN2(reads, writes) : MAX2(reads, writes);
<airlied>
./src/gallium/drivers/zink/zink_context.c:2273:1: warning: unused function 'zink_resource_buffer_barrier_init' [-Wunused-function]
<airlied>
your friendly neighbourhood build log transcriber
<Sachiel>
it's just warnings, those don't matter
<zmike>
they'll go away once more stuff lands
<airlied>
zmike: isn't that statement always true? :-P
<zmike>
damn you caught me
<zmike>
still weird that I never get these warnings when I build
<airlied>
zmike: in the clang build
<zmike>
ah
<zmike>
I guess that would do it
<airlied>
yeah I just happened to glance at the logs from the last crocus build for no real reason
<zmike>
I think all 3 of those are just getting deleted in upcoming MRs
<airlied>
well I'll keep reviewing then :-P
<zmike>
I'm probably gonna crash soon
<zmike>
feels good to be over the descriptor hump
<kusma>
Heh. In create_bci, we verify that the VkFormatProperties match the buffer usage. But, uh, all buffers are created with R8_UNORM format, it's the view formats that we need to verify the format support of...
omegatron has joined #zink
xroumegue has quit [Quit: WeeChat 2.3]
xroumegue has joined #zink
<hch12907>
that abs((int)reads - (int)writes) > UINT32_MAX / 2 condition is *weird*
<zmike>
it's getting nuked soon
<hch12907>
it is optimized into a zero by clang as far as I can tell
<zmike>
I don't use clang ¯\_(ツ)_/¯
<zmike>
it's not a realistic case to hit anyway unless you're running something for many days without crashing
<kusma>
zmike: So, Zink builds on MSVC now. But trying wglgears.exe on the resulting OpenGL32.dll gives me a black screen. If I place a breakpoint in zink_flush_frontbuffer, I see that the first frame gets the first draw-call drawn, but then nothing: https://i.ibb.co/FKx7N6H/zink-wglgears.png
<zmike>
huh
<kusma>
Do you have any idea what might be up? I guess this is the first time any of us is testing on the Intel Windows Vulkan driver? :P
<zmike>
a good start
<zmike>
not even the tiniest clue tbh
<kusma>
Yeah, I mean. Who needs more than one draw?
<zmike>
nobody imo
<zmike>
do it right the first time and you don't need a second
<kusma>
Exactly.
<zmike>
tried GALLIUM_TRACE yet?
<kusma>
Not yet, what kind of info do you think that would reveal?
<kusma>
I guess I should try the validator also.
<zmike>
well it'd reveal whether the driver is getting calls
<zmike>
might be stuck in winsys
<kusma>
Ah,no. I see calls :)
<kusma>
The FPS is flying past, for instance.
<kusma>
Probably way too fast, TBH
<zmike>
is it getting more than 1 flush_frontbuffer call?
<kusma>
Yes
<kusma>
Like, 630 FPS with a debug-build
<zmike>
well you could always just memcpy the first frame and memcmp it
<zmike>
to see if it's changing
<zmike>
if it is then it's a winsys problem
<zmike>
or vk proble
<kusma>
TBH, I have more a feeling that nothing is really syncing here.
<kusma>
I think this should have been vsync-locked.
<kusma>
Heh, enabling MSAA works, and gives me the same result, except the first frame has that one draw-call correctly anti-aliased.
<kusma>
So it seems we keep on rendering, but something is going wrong with the following draws somehow.
<kusma>
The validator complains about vkCreateBufferView calls, and flags. I guess I should tweak that code similar to what I ripped out recently!
<kusma>
Oh god. Do we really need to know what view-formats a buffer will be used with?
<kusma>
OK, that's not it in this case.
<kusma>
Heh, I found the issue, and boy is it dumb and trivial!
<kusma>
`screen->info.feats.pNext` is non-NULL when we call `vkCreateDevice` 🤦♂️
<zmike>
🤔
<hch12907>
🤔 indeed
<kusma>
Yeah, how that lead to that behavior is odd
<hch12907>
by the way, the emojis are all 口 according to hexchat - is there any preferred IRC client among mesa devs?
<zmike>
I use hexchat
<kusma>
Oh, I'm using Element + the OFTC Matrix bridge thingie. So maybe I'm at fault here :P
<hch12907>
huh, do the emojis display for you?
<zmike>
on fedora emojis show up fine, maybe missing fonts or something
<zmike>
I remember having that problem years ago when I used gentoo
<hch12907>
on arch everything non-latin1 is probably borked
<kusma>
But maybe it'd be better to fix the pNext to be NULL right after we call vkGetPhysicalDeviceFeatures2 instead? Dunno, and I don't think I care too much ;)
<kusma>
zmike: Derpy gears are back!
<kusma>
I've missed them ❤️
<zmike>
!
<zmike>
gimme a pic
<zmike>
I need my fix
<hch12907>
I'm surprised that vkGetPhysicalDeviceFeatures2 drops something non-null into pNext
<zmike>
the driver should handle that
<zmike>
I blame jekstrand
<jekstrand>
uh, what?
<hch12907>
it's a genuine proof that zink catches the weirdest edge cases in a VK driver!
<jekstrand>
that shouldn't be happening.
<jekstrand>
which vk driver?
<jekstrand>
which struct?
<hch12907>
windows VK
<kusma>
jekstrand: Intel Windows
<jekstrand>
Oh, well that's very much not my fault
<jekstrand>
Though, I thin, in theory, these days I could make a PR to fix it
<hch12907>
nothing about running zink on lavapipe either... I eventually decided to read the ci scripts
<zmike>
that's because it's not officially supported
<hch12907>
it isn't?
<zmike>
no
<zmike>
hence all the warnings when you do it
<hch12907>
I thought that since we ran all the CI tests with lvp+zink, it'd be at least semi-official
<zmike>
no
<hch12907>
I suppose that's a TIL for me
<zmike>
learn something new every day
<hch12907>
yep, it is intentional that we pass a pNext that points to the extension structs
<zmike>
cool
<zmike>
so I guess that's just a bug report for intel windows
<zmike>
thanks for double-checking it
<hch12907>
not sure which feature caused that though, HSW gets no vulkan love on windows
<jekstrand>
kusma: I'm looking at our Windows driver code and I really don't see how that's possible.
<jekstrand>
kusma: Do you have any layers which might be chaining in something extra?
<jekstrand>
Can someone verify that Zink is passing a NULL pNext into vkGetPhysicalDeviceFeatures2 and that it's non-NULL coming out?
<hch12907>
we found out that zink is actually intentionally passing a non-null pNext, to enable features obviously
<hch12907>
so I *think* we got that wrong, it's not giving us non-null pNext
<hch12907>
(just for clarification, we are passing a non-null pNext to vkCreateDevice)
<hch12907>
however, with a / some features turned on, the rendering is apparently broken
<kusma>
I'll debug further tomorrow
<jekstrand>
k
<zmike>
time to fuzz test feature enablement!
<kusma>
zmike: yeah, I've intentionally not included it, because the mesa docs already extensively documents how to build, and I don't want to duplicate that. I guess we could add a couple of sentences and link to the rest of the docs, though...
<zmike>
I clicked around a little today in the docs and wasn't immediately able to find it
<zmike>
so "extensively" may be accurate but that info isn't readily available
<zmike>
yea I found those, but at no point does it actually tell the reader how to build a gallium or vulkan driver
<zmike>
it's the same thing I see with cmake docs everywheree
<zmike>
people just assume everyone knows how to use it
<kusma>
I'm not sure what you mean by "how to build a gallium or vulkan driver"... You build and install mesa, and the drivers gets installed... If you mean `-Dgallium-drivers` etc, then maybe that should be added
<kusma>
On the other hand, maybe zink should be default on soon, and then that shouldn't matter...