06:01 fdobridge: <g​fxstrand> WTF! NVK+Zink just passed the EGL tests
06:10 fdobridge: <g​fxstrand> GLES2 and no hangs...
06:10 fdobridge: <g​fxstrand> Actually... two faults. But those might be EGL tests that are supposed to fault.
06:10 fdobridge: <g​fxstrand> I should go to bed and check the results in the morning.
12:15 fdobridge: <z​mike.> somewhat sure the buffer age ones were the only ones that failed
12:15 fdobridge: <z​mike.> they were historically hard to fix though
12:32 fdobridge: <k​arolherbst🐧🦀> some user want to use nvk with their `GeForce GT 610`
12:32 fdobridge: <k​arolherbst🐧🦀> :blobcatnotlikethis:
12:39 fdobridge: <m​agic_rb.> how much of what makes a modern GPU is the 610 generation missing at this point?
12:40 fdobridge: <r​hed0x> biggest problem is probably the GSP?
12:40 fdobridge: <S​id> nah
12:41 fdobridge: <k​arolherbst🐧🦀> speed mostly
12:41 fdobridge: <k​arolherbst🐧🦀> it's a slow GPU, and I mean slow
12:42 fdobridge: <S​id> the problem is missing hardware support for vulkan too, iirc
12:42 fdobridge: <S​id> but
12:42 fdobridge: <k​arolherbst🐧🦀> maybe around 5% of the RTX 1650?
12:42 fdobridge: <S​id> I could be wrong
12:42 fdobridge: <m​agic_rb.> i used to have a 650 ti boost in my desktop and a 610 i think in my laptop, used to play stalker ogse on proprietary drivers using wined3d back in the day, those were the days lmao
12:42 fdobridge: <S​id> GTX*
12:42 fdobridge: <k​arolherbst🐧🦀> and that's with full clcoks
12:42 fdobridge: <k​arolherbst🐧🦀> the 650 is probably 10x as fast
12:42 fdobridge: <m​agic_rb.> oh ok oof
12:43 fdobridge: <k​arolherbst🐧🦀> ehh.. not 10x, but like 7x 😄
12:43 fdobridge: <S​id> yeah Fermi doesn't have hardware support for vulkan
12:43 fdobridge: <S​id> so
12:43 fdobridge: <S​id> .-.
12:43 fdobridge: <m​agic_rb.> so its like the gt610 just being slow even in its own generation
12:43 fdobridge: <k​arolherbst🐧🦀> but in any case
12:43 fdobridge: <k​arolherbst🐧🦀> we can't change the clocks on fermi
12:43 fdobridge: <k​arolherbst🐧🦀> sooo...
12:43 fdobridge: <k​arolherbst🐧🦀> and fermi booted with like 50mhz 😄
12:43 fdobridge: <r​hed0x> i thought fermi still could be reclocked
12:43 fdobridge: <k​arolherbst🐧🦀> nah
12:43 fdobridge: <k​arolherbst🐧🦀> well
12:43 fdobridge: <k​arolherbst🐧🦀> it could if we would have the code for it
12:43 fdobridge: <k​arolherbst🐧🦀> which we don't
12:44 fdobridge: <m​agic_rb.> how much of it would have to be done in software? as in, what missing? cause i never actually understood why is hardware support required for vulkan/opengl4.6/dx12
12:44 fdobridge: <S​id> that's a question for karol
12:44 fdobridge: <S​id> or maybe faith
12:44 fdobridge: <k​arolherbst🐧🦀> it's uhm..
12:44 fdobridge: <S​id> or maybe mike
12:44 fdobridge: <z​mike.> @gfxstrand is there a reason why `borderColorSwizzleFromImage` is not supported? zink requires this
12:44 fdobridge: <r​hed0x> vulkan requires specific features and if the hardware cant do those, theres not much you can
12:44 fdobridge: <r​hed0x> vulkan requires specific features and if the hardware cant do those, theres not much you can do (edited)
12:44 fdobridge: <k​arolherbst🐧🦀> something with how texturing is done on fermi really sucks
12:45 fdobridge: <k​arolherbst🐧🦀> even in gl we don't enable bindless textures on fermi
12:45 fdobridge: <m​agic_rb.> whats a bindless texture
12:46 fdobridge: <r​hed0x> normally you need to bind textures before every draw with bindless textures you can basically access all of them in the shader without binding them every time
12:46 fdobridge: <r​hed0x> normally you need to bind the textures you want to use before every draw with bindless textures you can basically access all of them in the shader without binding them every time (edited)
12:46 fdobridge: <m​agic_rb.> oh okay that makes sense, i really should actually learn graphics programming and how gpus work, never managed to find the motivation and/or time
12:46 fdobridge: <m​agic_rb.> and im still not studying for the damn exam
12:47 fdobridge: <m​agic_rb.> 😭
12:53 fdobridge: <!​DodoNVK (she) 🇱🇹> Which WineD3D now uses
12:54 fdobridge: <n​anokatze> 610 and 650 are very different gens and 610 doesn't support lots of features
12:54 fdobridge: <n​anokatze> 610 is GF and 650 is GK
12:54 fdobridge: <m​agic_rb.> Fermi vs Kepler or subgens of fermi
12:54 fdobridge: <m​agic_rb.> I only know the marketing terms as of now
12:54 fdobridge: <n​anokatze> fermi vs kekler yes
12:54 fdobridge: <m​agic_rb.> Ah makes sense
12:55 fdobridge: <n​anokatze> thank you gpu vendors very cool
12:56 fdobridge: <n​anokatze> not sure why people brought up bindless textures, a gpu without those could still be useful, e.g. dxvk doesn't require that feature
12:56 fdobridge: <n​anokatze> but yes that's definitely old and slow
12:58 fdobridge: <a​huillet> ?
12:59 fdobridge: <n​anokatze> this was the question
12:59 fdobridge: <n​anokatze> this was one of the responses
12:59 fdobridge: <n​anokatze> to me it read like "fermi doesn't have bindless, therefore you can't implement vk on it"
12:59 fdobridge: <m​agic_rb.> that is what i read too
13:00 fdobridge: <S​id> fermi doesn't have hardware support for some stuff required for vk
13:00 fdobridge: <S​id> which is why you can't implement vk on it
13:00 fdobridge: <n​anokatze> which though
13:00 fdobridge: <S​id> whether or not bindless is a part of it, I do not know
13:00 fdobridge: <S​id> ¯\_(ツ)_/¯
13:00 fdobridge: <n​anokatze> I'm not sure that's true
13:00 fdobridge: <n​anokatze> whether it's worthwhile to implement vk on that is its own question though
13:01 fdobridge: <m​agic_rb.> afaik you can always do it on the cpu side, it might just be slow as hell
13:01 fdobridge: <n​anokatze> well, it's kinda implied that you'd do your damnest hardest to use the gpu the way it's meant to be used™️
13:02 fdobridge: <S​id> well, right now there's not a single vulkan driver for fermi
13:02 fdobridge: <S​id> so all the best :D
13:03 fdobridge: <!​DodoNVK (she) 🇱🇹> <https://youtu.be/vxNnUvdotA8?t=8m21s>
13:16 fdobridge: <n​anokatze> so why was the "?" 🐸
13:28 fdobridge: <r​edsheep> I don't know about the texturing, but in the past Faith explained that lack of certain ordering guarantees with Fermi and Kepler make vulkan memory model practically impossible. If the hardware is hard to reclock, slow in the first place, and could never get to vulkan 1.3, that doesn't seem worth the effort for either one.
13:32 fdobridge: <n​anokatze> probably another compounding factor is that there's only 0.5 people in existence that would actually use it
13:44 fdobridge: <p​ac85> What does the Kepler isa look like?
13:44 fdobridge: <p​ac85> Is it anything like the modern one?
14:13 fdobridge: <g​fxstrand> I'm pretty sure you can implement Vulkan on Fermi. The question is whether or not it's worth it.
14:13 fdobridge: <k​arolherbst🐧🦀> well..
14:14 fdobridge: <k​arolherbst🐧🦀> how much sense would it make without bindless images?
14:15 fdobridge: <r​hed0x> the trick is to bait @triang3l into doing it 🐸
14:17 fdobridge: <z​mike.> nobody has the time to review those comments
14:21 fdobridge: <n​anokatze> @ Rhedox react with pregnant frog to zmike's comment
14:24 fdobridge: <g​fxstrand> I've implemented Vulkan on plenty of non-bindless hardware. It's not that hard.
14:26 fdobridge: <p​ac85> Would that involve like assigning slots to descriptors during pipeline creation?
14:26 fdobridge: <r​hed0x> do i look like someone with discord nitro?
14:26 fdobridge: <!​DodoNVK (she) 🇱🇹> 🔺 is only an ATI/AMD expert right now
14:27 fdobridge: <p​ac85> Anyway I'd decide based on the number of users interested maybe
14:28 fdobridge: <m​arysaka> I still have my GT 440 around but why would we want a Vulkan driver on Fermi anyway...?
14:31 fdobridge: <m​agic_rb.> For the same reason as on an gen, if enough people want to use it. Id want good support on my 1060 but i know its not gonna happen probably ever.
14:31 fdobridge: <m​agic_rb.> Idk how many people there are that are still on fermi/kepler, since not even nvidia proprietary supports those
14:31 fdobridge: <m​agic_rb.> And the question is whether software vulkan/opengl would be faster anyway on modern cpus lol
14:33 fdobridge: <a​huillet> no, absolutely not
14:33 fdobridge: <a​huillet> that one is easy :)
14:33 fdobridge: <r​edsheep> While the steam hardware survey is imperfect I think it's notable that the only Fermi and Kepler cards still popular enough to get listed are the gt 710 and 730, which vary on being Fermi or Kepler.
14:33 fdobridge: <m​agic_rb.> :)
14:33 fdobridge: <r​edsheep> I don't think either gen is worth thinking about much.
14:35 fdobridge: <t​riang3l> Aside from bindless, how huge would shader compiler differences be? As far as I understand, Fermi has a completely different scheduling model, it's more like just scalar, though I don't know
14:38 fdobridge: <t​riang3l> But yeah, non-bindless is trivial, especially if each shader stage has its own binding spaces, in which case it maps directly to Vulkan pipeline layout compatibility
14:40 fdobridge: <t​riang3l> though I don't know if that's the case on Nvidia
14:41 fdobridge: <t​riang3l> at least on Nvidia because there's virtual memory you don't have to care about whether each descriptor is statically used also, but that's ez anyway still
14:41 fdobridge: <r​edsheep> Has anyone tested performance now that the control flow MR is in main? That would be expected to cut down on some of the stalling, right?
14:42 fdobridge: <t​riang3l> at least on Nvidia because there's virtual memory you don't have to care about whether each descriptor is statically used also, but that's ez anyway still (though for optimization you'd still like to skip them) (edited)
14:42 fdobridge: <t​riang3l> at least on Nvidia because there's virtual memory you don't have to care about whether each descriptor is statically used also, but that's ez anyway still (though for optimization you'd still like to skip updating unused ones) (edited)
15:05 fdobridge: <g​fxstrand> 🤷🏻‍♀️ They're all supported by codegen so probably not intractable.
15:05 fdobridge: <g​fxstrand> As long as it's still PTX-like, it's probably fine.
15:06 fdobridge: <g​fxstrand> It should get us better re-convergence which should help shaders with loops a bit.
15:06 fdobridge: <g​fxstrand> It fixed Genshin Impact's rendering issues.
15:09 fdobridge: <r​edsheep> Ok I can't reboot for that now but I'll probably see if it moved the needle tonight
15:16 fdobridge: <g​eorgeouzou> I'm playing with VK_EXT_descriptor_buffer. All buffer / texture descriptors seem to work ok, but texel buffers need some tricks to work. Lowering texelfetch to load_global_constant works but it's a little ugly as I am doing all format conversions in nir shader code
15:20 fdobridge: <g​fxstrand> Yup! Welcome to EDB hell.
15:20 fdobridge: <!​DodoNVK (she) 🇱🇹> Extended Dynamic Buffer?
15:21 fdobridge: <p​ac85> Ext descriptor buffer prob
15:23 fdobridge: <m​agic_rb.> Do new vulkan versions drop extensions? Or is additive only. As if extensions keep getting added for random stuff, itll just get way too bloated to implement
15:23 fdobridge: <m​agic_rb.> Do new vulkan versions drop extensions? Or is it additive only. As if extensions keep getting added for random stuff, itll just get way too bloated to implement (edited)
15:24 fdobridge: <m​agic_rb.> Do new vulkan versions drop extensions? Or is it additive only. Because if extensions keep getting added for random stuff, itll just get way too bloated to implement (edited)
15:25 fdobridge: <g​eorgeouzou> Some might get promoted to core
15:26 fdobridge: <g​eorgeouzou> And then deprecated
15:27 fdobridge: <t​riang3l> Is there any theoretical possibility of implementing it "as intended", by the way? I forgot what the issue was… can you treat descriptors as indices for non-EDB, and as views for EDB, or is that boundary crossed somewhere in an inconvenient way?
15:29 fdobridge: <g​eorgeouzou> Texture Descriptors live in a huge table . That can be instead be used as a descriptor buffer , but some things like meta code is hard to implement I think
15:29 fdobridge: <t​riang3l> From what I understand, the extensions that are deprecated are some really cursed stuff normally, like GLSL shaders, while promotion is a special kind of the "deprecation state", but not actually deprecated
15:30 fdobridge: <g​eorgeouzou> The proprietary driver seems to use indices to the table instead
15:30 fdobridge: <t​riang3l> But I think you may be able to not bother exposing promoted extensions as extensions on older versions, though I think [everyone would dislike that] among application developers
15:31 fdobridge: <g​eorgeouzou> The proprietary driver seems to use indices to the table instead for the descriptor_buffer extension (edited)
15:31 fdobridge: <t​riang3l> Ah, nowhere to place meta descriptors?
15:32 fdobridge: <t​riang3l> and having to maintain two versions of meta shaders for EDB and non-EDB?
15:33 fdobridge: <t​riang3l> pain, though Nvidia's DMA engine is powahful AFAIK, but not sure how much in reality
15:33 fdobridge: <g​eorgeouzou> You cannot switch tables without a cache flush and shader instructions use indices to a table for texture instructions
15:34 fdobridge: <g​eorgeouzou> I may miss something but this is what I understood
15:35 fdobridge: <g​eorgeouzou> You cannot switch tables without a cache flush and texture instructions use indices to a table to sample/fetch (edited)
15:35 fdobridge: <g​eorgeouzou> You cannot switch tables without a cache flush and texture instructions use indices to the descriptor table to sample/fetch (edited)
15:46 fdobridge: <g​fxstrand> I've been rolling it around in my brain for a while.
15:46 fdobridge: <g​fxstrand> I think binding the actual heap is possible but tricky
15:49 fdobridge: <z​mike.> disregard, this is just the profile being wrong...
15:54 fdobridge: <g​fxstrand> And... it randomly dies on KHR-GLES3.core.constant_expressions.basic_clamp_float_vertex for no obvious reason. 😩
15:56 fdobridge: <g​fxstrand> I kinda wonder if I'm fighting that old fencing issue
16:00 fdobridge: <t​riang3l> VM_BIND some 2^20 - 10^6 descriptors in all descriptor buffers to the same BO containing meta descriptors :happy_gears:
16:00 fdobridge: <t​riang3l> or still has inconvenient overhead?
16:01 fdobridge: <g​fxstrand> Yeah, that's roughly the plan I had.
16:01 fdobridge: <t​riang3l> though switching the meta descriptor sub-heaps would be _pain_ maaaybe
16:01 fdobridge: <g​fxstrand> For the sub-heap, we'd probably allocate as late as possible and DMA them in
16:02 fdobridge: <g​fxstrand> As long as you're stalling every 100'th blit and not every blit, it's fine.
16:04 fdobridge: <g​eorgeouzou> Thats the plan!
16:04 fdobridge: <!​DodoNVK (she) 🇱🇹> Is descriptor_buffer possible pre-GCN?
16:05 fdobridge: <t​riang3l> Not even update after bind is due to tiny binding count limits 😿
16:05 fdobridge: <t​riang3l> although the concept of update-after-bind descriptors is probably possible if you patch command buffers right before submitting :blobcatnotlikethis:
16:05 fdobridge: <g​fxstrand> Yeah, pre-GCN is stuck on the good ol' Vulkan 1.0 binding model.
16:05 fdobridge: <g​fxstrand> Yeah, patching seems very not worth it
16:06 fdobridge: <d​adschoorse> pre-GCN doesn't matter
16:06 fdobridge: <g​fxstrand> That's what I keep trying to tell people about pre-Turing but then someone wants NVK to run on a 610. 🙃
16:07 fdobridge: <t​riang3l> I just want to play the Quake 2 remaster, Doom 64, and Serious Sam Fusion 2017 :xenia_cry:
16:07 fdobridge: <d​adschoorse> pascal and even maxwell are still usable perf-wise, pre-gcn isn't
16:07 fdobridge: <p​ac85> Would it be possible to slap the meta descriptors in the heap itself? The meta descriptor would be reintepreted as a garbage descruptor if it where to be touched but I presume the hw doesn't care what's in it so long as nobody tries to use that particular descriptor right?
16:07 fdobridge: <t​riang3l> on a boomer graphics card
16:08 fdobridge: <m​ohamexiety> not on nouveau though, and iirc even on properietary it's not very usable on linux because dxvk/vkd3d destroy perf too much
16:08 fdobridge: <d​adschoorse> dxvk on pascal isn't bad
16:09 fdobridge: <m​agic_rb.> My 1060 is still completely fine, 1080 medium settings, works for most gamrs
16:09 fdobridge: <m​agic_rb.> My 1060 is still completely fine, 1080 medium settings, works for most games (edited)
16:10 fdobridge: <n​anokatze> EXT buffer device address is deprecated
16:10 fdobridge: <t​riang3l> I'll have to patch something anyway because DISPATCH_INDIRECT is totally broken in the kernel driver version from 2018 :blobcatnotlikethis:
16:10 fdobridge: <m​ohamexiety> oh. I see, what I heard gave me the impression it was much worse than that
16:10 fdobridge: <t​riang3l> I'll have to patch something anyway because DISPATCH_INDIRECT argument buffer relocation is totally broken in the kernel driver version from 2018 :blobcatnotlikethis: (edited)
16:11 fdobridge: <m​ohamexiety> my pascal is a 1030 so not the best judge of... anything, really here :blobcatnotlikethis:
16:11 fdobridge: <m​agic_rb.> Yeah it may dip, it may run at not 60 but like, still very much usable for the witcher, dying light 1/2, arma, probably even baldurs gate
16:11 fdobridge: <t​riang3l> but yeah, relaxing the descriptor validity requirement from statically used to dynamically used would also require some handling
16:12 fdobridge: <t​riang3l> like holding a list of descriptors referencing each texture/buffer and invalidating them when the latter is destroyed
16:12 fdobridge: <n​anokatze> it's more or less fine for drivers, you should be worried about people working on VVL
16:12 fdobridge: <t​riang3l> like holding lists of descriptors referencing each texture/buffer and invalidating them when the latter is destroyed (edited)
16:13 fdobridge: <m​agic_rb.> Whats vvl
16:13 fdobridge: <n​anokatze> vulkan validation layer
16:13 fdobridge: <m​ohamexiety> validation layers
16:13 fdobridge: <n​anokatze> they should rename it to just layer because it's a single layer now
16:14 fdobridge: <n​anokatze> hasn't been layers in years
16:14 fdobridge: <t​riang3l> I don't even know what to do with "emulated" buffer device address with implicit sync btw
16:14 fdobridge: <n​anokatze> just don't
16:14 fdobridge: <t​riang3l> since lots of BOs potentially not actually touched by the shaders will be referenced in every submission
16:15 fdobridge: <n​anokatze> accept that buffer device address wins and memescale loses
16:15 fdobridge: <n​anokatze> (loses buffer device address)
16:15 fdobridge: <t​riang3l> since lots of BOs potentially not actually touched by the shaders will be referenced in every submission, and vkFreeMemory will probably have to wait a lot spuriously (edited)
16:16 fdobridge: <p​ac85> Poor triangle
16:16 fdobridge: <p​ac85> But everyone is right
16:16 fdobridge: <n​anokatze> ye, everyone is always right
16:17 fdobridge: <t​riang3l> maybe on windows :nope_gears:
16:17 fdobridge: <p​ac85> Poor triangel (edited)
16:17 fdobridge: <p​ac85> STOP IMMEDIATELY
16:17 fdobridge: <n​anokatze> yes do it
16:17 fdobridge: <t​riang3l> though it has implicit sync for mapping BOs
16:18 fdobridge: <p​ac85> Why
16:18 fdobridge: <t​riang3l> maaaybe that's even the only real way of GPU>CPU sync on Vista, I don't even know
16:18 fdobridge: <n​anokatze> those entire 1/3 memescale users will enjoy it
16:18 fdobridge: <n​anokatze> on windows
16:18 fdobridge: <t​riang3l> though it has implicit sync for mapping BOs at least (edited)
16:18 fdobridge: <p​ac85> One of them is triangel
16:18 fdobridge: <n​anokatze> those entire 0.5 memescale users will enjoy it (edited)
16:18 fdobridge: <t​riang3l> Xi3 Piston users
16:19 fdobridge: <n​anokatze> I had to actually look wtf that is
16:19 fdobridge: <n​anokatze> I had to actually look up wtf that is (edited)
16:19 fdobridge: <p​ac85> OK let's trigger nano
16:19 fdobridge: <p​ac85> Vulkan a ps3 when
16:19 fdobridge: <t​riang3l> a Steam Machine that apparently lost Volvo's blessing :blobcatnotlikethis:
16:19 fdobridge: <p​ac85> SPUs as asynchronous compute queue
16:20 fdobridge: <n​anokatze> :shocked:
16:20 fdobridge: <!​DodoNVK (she) 🇱🇹> I actually have a HD 4350 in a basement
16:21 fdobridge: <p​ac85> :frog_ancient:
16:21 fdobridge: <n​anokatze> that'd be your only option for compute
16:22 fdobridge: <t​riang3l> mandatory LDS caching for global accesses :blobcatnotlikethis:
16:22 fdobridge: <p​ac85> So you'd have 3 ISAs for vertex fragment and compute
16:22 fdobridge: <t​riang3l> mandatory LDS caching for global memory accesses :blobcatnotlikethis: (edited)
16:22 fdobridge: <t​riang3l> mandatory manual LDS caching for global memory accesses :blobcatnotlikethis: (edited)
16:22 fdobridge: <p​ac85> So you'd have 3 different ISAs for vertex fragment and compute (edited)
16:22 fdobridge: <n​anokatze> it doesn't have to be mandatory, you can implement smt/coroutines + software cache, I read a cell rt paper from 2005 that did that
16:22 fdobridge: <n​anokatze> very un-unified
16:22 fdobridge: <n​anokatze> extremely even\
16:23 fdobridge: <p​ac85> Extremely uneven*
16:24 fdobridge: <!​DodoNVK (she) 🇱🇹> And an even older GPU in the first PC I used
16:24 fdobridge: <p​ac85> I thought you where like younger than me
16:24 fdobridge: <p​ac85> Why do you have ancient hw
16:26 fdobridge: <g​fxstrand> I still kinda want to see someone implement Vulkan for the PS3 using the cell processors for compute shaders.
16:26 fdobridge: <!​DodoNVK (she) 🇱🇹> I guess limited money (I used that HD 4350 back in my 2017 PC with a Q6600)
16:26 fdobridge: <p​ac85> Vulkan on a ps3 when (edited)
16:26 fdobridge: <m​ohamexiety> we may kinda get something similar to this if someone writes a Vulkan implementation for some of the upcoming NPUs
16:26 fdobridge: <p​ac85> Ah
16:27 fdobridge: <m​ohamexiety> some architectures are similar to the Cell in a way
16:27 fdobridge: <t​riang3l> And the Nvidia GPU for the graphics pipeline? That'd be double impressive
16:27 fdobridge: <p​ac85> Oh yeah amd announced something that looked a lot like cell
16:27 fdobridge: <t​riang3l> but not sure if it even has stuff like integers, probably not?
16:27 fdobridge: <!​DodoNVK (she) 🇱🇹> Next article: Trans Hacker Implements a Low-Level Graphics API on Supercomputer Level Game Console
16:30 fdobridge: <t​riang3l> OpenGL shaders via blending, intermediate framebuffers and LUTs on PS2's GS?
16:31 fdobridge: <!​DodoNVK (she) 🇱🇹> The PS2 GS got dropped fairly early
16:33 fdobridge: <g​fxstrand> @valentineburley do you want to take over maintenance6? I think most of what needs to be done is switching to the 2 versions of descriptor entrypoints (no need to copy+paste, we have fallbacks for that) and running `*maintenance6*`. The block compatible array images stuff should already work.
16:42 fdobridge: <!​DodoNVK (she) 🇱🇹> How about `fragmentShadingRateClampCombinerInputs`?
16:49 fdobridge: <g​fxstrand> Someone has to implement fragment shading rate first. 🙃
16:49 fdobridge: <g​fxstrand> Just kicked off a tip-of-tree CTS run. Wish me luck!
16:52 fdobridge: <g​fxstrand> Or not. Machine died instantly. :blobcatnotlikethis:
16:55 fdobridge: <g​fxstrand> @airlied I keep hitting these
16:55 fdobridge: <g​fxstrand> https://cdn.discordapp.com/attachments/1034184951790305330/1222227421273653359/backtrace?ex=661572fd&is=6602fdfd&hm=dd86b8798cf8cafd52deb9d6cb559f8fadd06b09f2ce29740d2adaec1086fddd&
17:07 fdobridge: <!​DodoNVK (she) 🇱🇹> Is there a way to tell if a Vulkan driver (like :triangle_nvk:) meets the Vulkan .json profile requirements? 🍩
17:08 fdobridge: <r​inlovesyou> https://github.com/KhronosGroup/Vulkan-Tools/blob/main/vulkaninfo/json_validation_process.md ?
17:09 fdobridge: <!​DodoNVK (she) 🇱🇹> I didn't know this existed in vulkaninfo
17:09 fdobridge: <r​inlovesyou> yee hope this is helpful
17:13 fdobridge: <v​alentineburley> Sure, I'll try to in a bit. What fallbacks do you mean? (I haven't really looked into it yet, just want to make sure I'm not misunderstanding something)
17:13 fdobridge: <v​alentineburley> Thank you!
17:14 fdobridge: <!​DodoNVK (she) 🇱🇹> Actually this just tests the validity of the .json file I think
17:21 killmlana: hello, was wondering if anyone else is encountering issues with hdmi digital output with the latest nouveau version for NV176 (GA106) Amphere.
17:26 fdobridge: <r​hed0x> i have a bunch of issues with display port, idk about hdmi
17:36 killmlana: ohhh what kind of issues, currently i am not getting audio output from the jack in my monitor, yeah sorry it's connected via display port as well. The jack on my mobo works fine.
17:38 DodoGTA: killmlana: Do you have GSP enabled?
17:44 fdobridge: <r​inlovesyou> yeah displayport audio not working is known, although i haven't tested it without gsp yet
17:44 fdobridge: <r​inlovesyou> also rip
17:57 fdobridge: <g​fxstrand> In the common code, we have implementations of most old entrypoints in terms of the 2KHR version so all you need to do is convert NVK to the newest version of the entrypoint.
18:15 fdobridge: <v​alentineburley> Great, thanks. I'll check it out as soon as I can.
18:23 fdobridge:<g​fxstrand> throws in a few `BUG_ON` to see if I can figure out where it's going off the rails.
18:23 fdobridge: <g​fxstrand> _throws in a few `BUG_ON` to see if she can figure out where it's going off the rails._ (edited)
19:11 fdobridge: <a​irlied> must be some race somewhere in pte allocations
19:11 fdobridge: <a​irlied> it at least isn't on bar mappings, do you hit if often?
19:15 Lyude: btw dakr airlied - I can take a look at your current rust patches on the ML today or tomorrow if y'all want
20:37 fdobridge: <a​irlied> @gfxstrand can you use addr2line I think it is to work out what line in nvkm_vmm_iter is crashing?
20:38 airlied: dakr: ^ can you look at the backtrace gfxstrand posted above and see if you have any clues
20:38 fdobridge: <a​irlied> @gfxstrand usual questions how often, and anything special to reproduce it more?
20:39 dakr: Lyude, sure, that's appreciated.
20:40 dakr: airlied, sure, will have a look.
20:41 fdobridge: <g​fxstrand> I pulled a fresh CTS and I'm hitting it pretty quickly on my setup. Unfortunately, if there's one thing I've learned about my setup, it's that it's unreproducible. 😂
20:53 fdobridge: <a​irlied> yeah I still haven't gotten my 36 thread CPU 😛
20:54 fdobridge: <r​edsheep> Wonder if my 32 thread CPU would hit it. I've still never tried out the cts
21:20 fdobridge: <g​fxstrand> To the "Hos often?" question, it's kinda random. Sometimes I can do a bunch of runs back-to-back and be fine. Then sometimes it'll fall over in less than 3 min
21:24 fdobridge: <g​fxstrand> Hit it in 23 seconds but it didn't hit my `BUG_ON()`
21:25 fdobridge: <a​irlied> yeah need to work out which ptr indirection is getting a NULL
21:26 fdobridge: <s​amantas5855> How come nova started getting attention?
21:26 fdobridge: <s​amantas5855> Is it usable
21:27 fdobridge: <a​irlied> it got attention because the intent to develop it was announced
21:29 fdobridge: <g​fxstrand> `/home/faith/projects/linux/nvk/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:544 (discriminator 1)`
21:29 fdobridge: <g​fxstrand> @airlied It seems to happen pretty often with tip-of-tree CTS and deqp-runner. @dwlsalmeida is hitting it as well so I know it's not just me this time. 😅
21:30 fdobridge: <g​fxstrand> ` if (ref && NVKM_VMM_PDE_INVALID(pgd->pde[pdei])) {`
21:30 fdobridge: <a​irlied> okay so pgd is probably null
21:31 fdobridge: <g​fxstrand> Let me BUG_ON that
21:31 fdobridge: <a​irlied> I'll throw some tip CTS runs at my machine today and see if I can spot it
21:44 fdobridge:<g​fxstrand> really should figure out a better kernel development flow than re-installing a full fedora set of signed modules every time.
21:47 fdobridge: <k​arolherbst🐧🦀> what's the proper way to run the VK CTS headless? I kinda seem to mess up on my pi...
21:51 fdobridge: <a​irlied> it should just run headless
21:52 fdobridge: <a​irlied> only the wsi tests should care about a head, and they won't run if one isn't there
21:52 fdobridge: <g​fxstrand> `-Dplatforms=` and no WSI tests will run
21:52 fdobridge: <k​arolherbst🐧🦀> mhh.. maybe the v3dv driver is just weird there then
22:06 fdobridge: <g​fxstrand> Ugh... This `addr2line` makes no sense
22:07 airlied: objdump -S can also be used to narrow stuff down
22:07 fdobridge: <g​fxstrand> Oh, it's because I didn't actually install the modules
22:07 fdobridge: <g​fxstrand> Silly initram
22:18 fdobridge: <g​fxstrand> @airlied `pgd == NULL`
22:18 fdobridge: <g​fxstrand> `drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c:544` (ish)
22:29 fdobridge: <g​fxstrand> Why is the page table NULL and what are we not validating? IDK.
22:32 fdobridge: <g​fxstrand> It's an unmap going sideways. That much is clear
22:34 fdobridge:<g​fxstrand> is very confused by the locking in this fiel
22:34 fdobridge: <g​fxstrand> _is very confused by the locking in this file_ (edited)
22:38 fdobridge: <g​fxstrand> More specifically, it's an unmap in a sparse region going sideways
22:39 fdobridge: <g​fxstrand> Maybe it's a large sparse map and someone is garbage collecting the PTEs?
22:39 fdobridge: <g​fxstrand> That sounds plausible.
23:16 fdobridge: <a​irlied> so it.pt[it.lvl] is NULL, any idea what lvl is?
23:16 fdobridge: <g​fxstrand> I can get that for you
23:19 airlied: dakr: ^ more info, you might know that code better
23:19 airlied: it might be worth just bailing on a NULL ptr and seeing if it has any unwarranted side effects
23:21 fdobridge: <g​fxstrand> It bothers me a bit that the sparse unmap code and the unmap code are so different.
23:21 fdobridge: <g​fxstrand> Like, they should be pretty much the same except for setting the VOL bit.
23:43 fdobridge: <g​fxstrand> @airlied , dakr: `it.lvl = 2`
23:44 fdobridge: <g​fxstrand> That's definitely in the middle of the tree