ChanServ changed the topic of #dri-devel to: <ajax> nothing involved with X should ever be unable to find a bar
glennk has quit [Ping timeout: 480 seconds]
Mangix has quit [Read error: Connection reset by peer]
Mangix has joined #dri-devel
rgallaispou has quit [Ping timeout: 480 seconds]
Lucretia has quit [Ping timeout: 480 seconds]
Lucretia has joined #dri-devel
epoch101 has quit []
heat has quit [Ping timeout: 480 seconds]
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
epoch101 has joined #dri-devel
melnary has joined #dri-devel
melnary is now known as melonai
melonai is now known as melnary
Haaninjo has quit [Quit: Ex-Chat]
DarkShadow4444 has joined #dri-devel
DarkShadow44 has quit [Ping timeout: 480 seconds]
ced117 has quit [Ping timeout: 480 seconds]
iive has quit [Quit: They came for me...]
YuGiOhJCJ has joined #dri-devel
xroumegue has quit [Ping timeout: 480 seconds]
mbrost has quit [Ping timeout: 480 seconds]
pa- has quit [Ping timeout: 480 seconds]
pa has joined #dri-devel
xroumegue has joined #dri-devel
Mangix has quit [Read error: Connection reset by peer]
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
Mangix has joined #dri-devel
ced117 has joined #dri-devel
pcercuei has quit [Quit: dodo]
mbrost has joined #dri-devel
alane has quit []
alane has joined #dri-devel
nerdopolis has quit [Ping timeout: 480 seconds]
YuGiOhJCJ has quit [Quit: YuGiOhJCJ]
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
lina has quit [Ping timeout: 480 seconds]
mbrost_ has joined #dri-devel
cmichael has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
mbrost_ has quit [Ping timeout: 480 seconds]
Lightsword_ has left #dri-devel [#dri-devel]
Lightsword has joined #dri-devel
kasper93_ has joined #dri-devel
oneforall2 has joined #dri-devel
kasper93 has quit [Ping timeout: 480 seconds]
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
Daanct12 has joined #dri-devel
<DemiMarie>
I’ve been convinced that userspace command submission is a good thing, if it does not expose new attack surface in the kernel and/or firmware by allowing userspace to do things it otherwise could not, and if the kernel is still in control of which rings are runnable at any given time. It seems that both of those hold on all recent hardware.
simon-perretta-img has quit [Read error: Connection reset by peer]
bmodem has joined #dri-devel
kts has joined #dri-devel
epoch101 has quit []
cmichael has quit [Quit: Leaving]
mbrost has joined #dri-devel
NiGaR has quit [Read error: Connection reset by peer]
NiGaR has joined #dri-devel
Daanct12 has quit [Read error: Connection reset by peer]
Daanct12 has joined #dri-devel
glennk has joined #dri-devel
caitcatdev has quit []
chiku has quit []
loki_val has joined #dri-devel
Sid127 has joined #dri-devel
crabbedhaloablut has quit [Ping timeout: 480 seconds]
caitcatdev has joined #dri-devel
kts has quit [Quit: Leaving]
NiGaR has quit [Read error: Connection reset by peer]
<karolherbst>
I'm git bisecting and cmake picks the wrong llvm 🙃
Daanct12 has quit [Quit: WeeChat 4.4.3]
u-amarsh04 has quit []
u-amarsh04 has joined #dri-devel
kts has joined #dri-devel
epoch101 has joined #dri-devel
Guest8727 has quit [Ping timeout: 480 seconds]
warpme has quit []
jsa1 has quit [Ping timeout: 480 seconds]
warpme has joined #dri-devel
<dcbaker>
karolherbst: you can set it on the command line or in the [built-in options] section. I think it’s module prefix though and has different semantics than pkg_config_path, namely that it points at a prefix like ~/install rather than pkg configs ~/install/lib/pkg-config
fab has joined #dri-devel
oneforall2 has quit [Read error: Connection reset by peer]
fab is now known as Guest8742
azerov has joined #dri-devel
warpme has quit [Read error: Connection reset by peer]
simon-perretta-img has quit []
dsimic is now known as Guest8743
dsimic has joined #dri-devel
oneforall2 has joined #dri-devel
Guest8743 has quit [Ping timeout: 480 seconds]
leroivi has quit [Ping timeout: 480 seconds]
mbrost has joined #dri-devel
paulk-bis has quit [Ping timeout: 480 seconds]
paulk has joined #dri-devel
bolson has joined #dri-devel
simon-perretta-img has joined #dri-devel
rasterman has quit [Quit: Gettin' stinky!]
kzd has joined #dri-devel
himal has quit [Ping timeout: 480 seconds]
paulk has quit [Quit: WeeChat 3.0]
<Company>
dzn doesn't like GTK's shaders
<Company>
or rather: DXIL doesn't
paulk has joined #dri-devel
<Company>
considering the whole code says "this is massively experimental, don't use for anything serious" I decided that's expected, but wanted to mention that I tried playing with it
warpme has joined #dri-devel
tzimmermann has quit [Quit: Leaving]
MrCooper_ is now known as MrCooper
kts has quit [Ping timeout: 480 seconds]
<MrCooper>
Company: jenatali might have pointers for Windows software rendering in GTK's CI
<Company>
I think I asked him before but there was no clear conclusion
<Company>
other than native D3D12 being best of course
<Company>
there was also the issue about how to get it installed in the CI runners - ie there's official packages for GLon12 but not for llvmpipe
<Company>
though at least for Vulkan, you can just set an env var, so lavapipe in CI would work if you had a DLL
<Company>
there's also the benefit that when using llvmpipe/lavapipe in CI, I get mostly the same behaviour as on Linux
<Company>
which makes tests less likely to fail
<Company>
stuff like rounding behavior when writing0.5 into a UNORM texture
<MrCooper>
AFAICT the Mesa CI windows-msvc job builds lavapipe, not sure if that produces anything usable by GTK CI though
mbrost_ has joined #dri-devel
<Company>
got a link to a DLL?
<Company>
Vulkan is just VK_DRIVER_FILES=some_icd.json that has a path to a DLL, so things are easy to test
<Company>
assuming that DLL doesn't depend on 15 other DLLs of course
<Company>
I didn't try building llvmpipe yet because of the llvm dependency
<Company>
alyssa: this is (1) I want to be able to debug what I'm doign wrong and I'm used to read source code - which is why I wanted dzn over "error in amdvlk.dll"
<alyssa>
ahhh
<alyssa>
yeah, fair
<Company>
alyssa: and (2) I'm looking for a way to make our CI run the Vulkan tests on Windows
<Company>
so that I can check that vkImportMemoryWin32HandleKHR() and VK_KHR_surface_win32 usage and whatnot is correct
<Company>
jenatali: I only tried to run it and it returned OUT_OF_MEMORY errors because DXIL.dll didn't convert things right
<jenatali>
Company: Got something for me to debug?
frankbinns has quit [Ping timeout: 480 seconds]
<DemiMarie>
jenatali: is MesaMatrix mistaken there?
rgallaispou has quit [Read error: Connection reset by peer]
Kayden has quit [Quit: -> JF]
<DemiMarie>
jenatali: do you mean lines 428 (Vulkan 1.1) and 454 (Vulkan 1.2)?
<jenatali>
I just mean that overall section of the file is stale
<DemiMarie>
jenatali: also, that reminds me: does any part of Windows call the WDDM KMD interface _other_ than via the UMD?
<DemiMarie>
Ah
imbris[m] has joined #dri-devel
<DemiMarie>
The reason I ask is because the most obvious way to support virtio-GPU native contexts on Windows is DXVK + Mesa in userspace talking to a Windows virtio-GPU KMD, but I am not sure how hard it would be to expose the WDDM interfaces, some of which (such as modesetting) do not even make sense.
<jenatali>
Windows has a paravirtualization infrastructure with a publicly documented protocol
<jenatali>
Company: Just to be clear, dzn converts SPIR-V to DXIL internally, but then D3D expects the resulting DXIL to be validated and "signed." DXIL.dll is the validator. It was closed-source but that recently changed: https://devblogs.microsoft.com/directx/open-sourcing-dxil-validator-hash/
<jenatali>
But yeah lavapipe should also work just fine
<DemiMarie>
jenatali: That would be a problem then, especially because Qubes OS generally puts complexity on the guest side to reduce attack surface. Where is the protocol documented?
<DemiMarie>
jenatali: Ah, so that would require something to emulate Hyper-V’s VMBus. QEMU might be able to do that.
<Company>
jenatali: I put that right next to it
<Company>
maybe I need some debug flags?
jsa1 has quit [Ping timeout: 480 seconds]
<Company>
how do I get the debug_printf()'s?
rasterman has joined #dri-devel
<jenatali>
Company: Oh, apparently we don't do the same search shenanigans for dxcompiler.dll. Windows DLL search paths are next to the exe, in PATH, and in System32. For dxil.dll which is needed at retail, we explicitly also search next to vulkan_dzn.dll but for dxcompiler.dll which is only needed for debugging we don't
<jenatali>
I thought debug_printfs go to stderr, maybe only in debug builds though
<Company>
yeah, apparently needs EMSA_DEBUG which needs -Dbuildtype=debug
<Company>
which is now rebuilding
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit []
tobiasjakobi has joined #dri-devel
tobiasjakobi has quit [Remote host closed the connection]
warpme has joined #dri-devel
warpme has quit []
<Company>
VSCode cross-project debugging is not the greatest thing
<jenatali>
Company: If you can extract the SPIR-V that's failing (text or binary) and file an issue I can take a look
<Company>
first I get this working
kaiwenjon has quit [Quit: WeeChat 3.8]
sukuna has joined #dri-devel
Company has quit [Read error: Connection reset by peer]
kaiwenjon has joined #dri-devel
frankbinns has joined #dri-devel
frankbinns has quit [Ping timeout: 480 seconds]
Company has joined #dri-devel
<Company>
I hve no idea why Windows claims it loads DLLs in PATH and then it doesn't - I bet there's some weird security flag somewhere that nobody talks about that disallows this somehow
<Company>
error: Semantic 'TEXCOORD' overlap at 3. Validation failed.
<jenatali>
I expect this is going to actually fix a bunch of GL tests
<Company>
let's see what happens when I build it
cyrinux has quit []
<Company>
how does spirv_to_dxil compare with spirv cross btw?
<Company>
if I ever attempt a D3D12 backend for GTK
cyrinux has joined #dri-devel
<jenatali>
spirv-cross goes to HLSL. spirv_to_dxil does not
<jenatali>
From a performance standpoint it should be faster
<jenatali>
Not that I've personally measured it though
<alyssa>
they also.. solve different problems, I think?
<Company>
I just need dxil I guess
<alyssa>
also i assume in the near future, you can just throw glslang spirv at d3d12 maybe..?
<Company>
in the end I just have some fairly simple code that needs to create glsl, spirv and dxil
<jenatali>
Maybe. TBD what D3D's SPIR-V environment will look like relative to GL/VK and whether glslang will be updated to produce it
<jenatali>
Clearly the solution is to also upstream GLSL into Clang :P
<Company>
at least that would produce better error messages
<Company>
success
<Company>
well, it compiles all the shaders, then displays half a second of stuff, then it gets a VK_ERROR_OUT_OF_POOL_MEMORY - but I'll blame GTK for that for now
<Company>
yup, it's GTK's fault
<Company>
we're waiting for OUT_OF_POOL_MEMORY, then reallocating the pool - but we also get a debug report about the error and we report on errors
<Company>
whoops
kaiwenjon has joined #dri-devel
<jenatali>
:)
mbrost_ has joined #dri-devel
mbrost has quit [Ping timeout: 480 seconds]
Calandracas has quit [Remote host closed the connection]
Calandracas has joined #dri-devel
epoch101 has quit []
linkmauve has left #dri-devel [Error from remote client]
mbrost_ has quit [Ping timeout: 480 seconds]
<Company>
booo!
<Company>
dzn claims it does VK_COMPOSITE_ALPHA_PRE_MULTIPLIED_BIT_KHR but I get black borders
gouchi has quit [Remote host closed the connection]
<Company>
oh
<Company>
that looks like an easy patch
<jenatali>
Yeah probably just an oversight
<jenatali>
WSI stuff is hard to test
<Company>
it can even do unpremultiplied alpha
marc2377 has quit [Quit: Leaving]
<Company>
jenatali: looking at this, here's another fun question: On VkSwapchainCreateInfoKHR.clipped == TRUE, is setting DXGI_SWAP_EFFECT_FLIP_DISCARD valid or not?
<jenatali>
What's clipped supposed to do?
<Company>
I know I've had this discussion before
<Company>
that's for the old X11 model
<Company>
when the buffer is shared between multiple swapchains and it's using clipping to restrict which images get drawn
<Company>
*which pixels of the image
<Company>
but various developers have interpreted that as "may discard buffer contents"
<jenatali>
Ah ok. D3D11 had a "guard rect" feature that did this but 12 doesn't
apinheiro has quit [Quit: Leaving]
<jenatali>
If you're interpreting it as "may discard buffer contents" then sure, flip-discard would be valid. In practice there's not much difference these days
<jenatali>
Originally it was to allow an optimization where the compositor would "reverse compose" overlay content into an app's swapchain and then send it out to display, to optimize for fill rate. Nowadays everything just uses multiplane overlay hardware to do that, so that path is dead AFAIK. It was always buggy anyway
<Company>
yeah, it feels like it can go wrong
<Company>
so I'll just not touch it if it's not worth it