15:16 ubitux: hi; I'm looking for information on what's exactly missing in hasvk for vk 1.0
15:16 ubitux: any idea where i could find this info?
15:17 ubitux: docs/features.txt is explicit for the later extensions, but not for the baseline
15:29 kisak: I'm probably wrong here, but I seem to recall there being a major issue with Ivybridge / Hawswell's memory model and the kernel module that wasn't fixable for the Vulkan driver.
17:23 mainiomano: ubitux: Sampler border colors are pretty problematic on Haswell because the format they need to be specified in depends on the texture format they will be used with
17:23 mainiomano: so the current implementation is pretty broken
17:24 mainiomano: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/intel/ci/hasvk-hsw-fails.txt lists what CTS tests are currently broken, but there's lots of features that could be implemented, but just haven't been, too
17:26 ubitux: ah that list looks useful, thank you
17:28 ubitux: that's a lot of different types of failure
22:57 zf: I'm seeing glClientWaitSync(..., INT64_MAX) return GL_TIMEOUT_EXPIRED on radeonsi, which obviously shouldn't happen. What kind of environment variables can I pull out to debug this, if any?
23:22 HdkR: zf: Have you timed how long it takes for it to timeout?
23:30 zf: HdkR: ~300 ns, so near instantaneous, and in the past half hour I also discovered that (INT64_MAX >> 1) seems to work correctly
23:30 HdkR: ah fancy
23:31 zf: oops, that's not the right number...
23:32 zf: 30 µs rather, sorry, off by two digits
23:32 zf: still, the theory seems promising
23:40 zf: strace shows a FUTEX_WAIT_BITSET with a negative tv_sec
23:47 HdkR: Sounds like a proper bug
23:48 HdkR: Wonder if it special cases UINT64_MAX instead of INT64_MAX for a forever wait
23:48 HdkR: Breaking with a nearly forever wait :)