orbea has quit [Quit: You defeated orbea! 2383232 XP gained!]
orbea has joined #zink
turol has quit [Ping timeout: 480 seconds]
turol has joined #zink
<graphitemaster>
zmike, The mipmap selection bug is not NV Vulkan related, it's also a lower mip with radv on the rx 580
<zmike>
huh?
<graphitemaster>
The weird bug I was having with zink being different than native GL when selecting a miplevel of a rendered cubemap
<zmike>
ah
<graphitemaster>
Seemingly selecting a different mip, though it could still be something else.
<graphitemaster>
Tried different hardware and it's the same there, so either mip selection is somehow broken (highly unlikely)
<graphitemaster>
Or there's something with rendering to individual mip levels of individual faces of the cubemap
<graphitemaster>
Which I think is more likely.
<graphitemaster>
I'll probably dump the cubemap itself today to see what is actually in there.
<zmike>
best idea would be to try and find a cts case or piglit test with similar mechanics
<graphitemaster>
I don't know much about Vulkan but how does one even render into a specific mip level of a cubemap
<graphitemaster>
Do you just create vkImageView for each miplevel and render into that view with VkDescriptorImageInfo
<zmike>
hm haven't done that yet
<zmike>
might be a jekstrand question
* jekstrand
materializes
<jekstrand>
graphitemaster: Yes, that's exactly how you do it.
<jekstrand>
graphitemaster: Cubes in Vulkan are just arrays with a multiple-of-six number of layers and CUBE_COMPATIBLE_BIT. Otherwise, you can treat them the same as any other array texture.
<graphitemaster>
jekstrand, So for a VkImage, a cubemap is a VK_IMAGE_TYPE_2D with arrayLayers=6, with flags having VK_IMAGE_CREATE_CUBE_COMPATIBLE, but for the actual VkImageView for faces (and miplevels) of that, the type is VK_IMAGE_VIEW_TYPE_CUBE. That's super inconsistent eh.
<jekstrand>
graphitemaster: You can also use VK_IMAGE_VIEW_TYPE_2D_ARRAY
<jekstrand>
Or VK_IMAGE_VIEW_TYPE_2D, I think
<jekstrand>
(I might be wrong about that last one)
<graphitemaster>
Was just stepping through Zink, my engine might be doing something horrible to confuse it. I create an FBO where I attach each face of the cubemap individually because the _order_ of attaching a whole cubemap in GL is different from what I want. I just don't enable any of them as draw buffers for rendering to until I render that face, so I end up having GL_COLOR_ATTACHMENT0 + face through each face we render.
<graphitemaster>
And there may be a possibility some confusion is happening here with understanding faces + miplevels
<graphitemaster>
Because the actual attached faces I put into the cubemap are not always the same miplevel
<graphitemaster>
s/cubemap/framebuffer/
<graphitemaster>
e.g face +x, +y, +z may be level 0, but -x, -y, -z might be level 1 :P
<jekstrand>
Fun...
<graphitemaster>
Technically speaking the engine updates faces of the cubemap that are actually visible and further ones away it only updates lower mip-levels based on the camera distance
<graphitemaster>
This would actually be distance to face, so not all faces share the same mip-level for a given update
<graphitemaster>
Which is really a mess to do with one FBO and draw buffer enablement
<graphitemaster>
I should just make it less clever and more naive to see if all that confusion is messing up Zink somehow