00:04 fdobridge: <k​arolherbst🐧🦀> I should poke again on the header documentation stuff 😄
00:06 fdobridge: <g​fxstrand> Yeah, zero linking is required
00:06 fdobridge: <g​fxstrand> The only thing you really need to link against is a few MSAA details.
00:06 fdobridge: <g​fxstrand> Of course, running cross-stage DCE may still help but that's different from there being an actual requirement.
00:07 fdobridge: <k​arolherbst🐧🦀> right...
00:07 fdobridge: <k​arolherbst🐧🦀> and codegen doesn't do that atm anyway
00:11 fdobridge: <g​fxstrand> `Pass: 282250, Fail: 5764, Crash: 17187, Skip: 1680995, Timeout: 32, Flake: 183, Duration: 59:00`
00:11 fdobridge: <a​irlied> Just implement EXT_shader_object 🙂
00:14 fdobridge: <g​fxstrand> I think that may be the long-term plan
00:14 fdobridge: <g​fxstrand> NVK being a shader-object-only driver, that is.
00:15 fdobridge: <a​irlied> Yeah and stack pipelines on via runtime?
00:20 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> But that isn't GPL
00:21 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> It's a closed-source extension /s
00:24 fdobridge: <k​arolherbst🐧🦀> I'm actually wondering if going forward shader objects will be the de facto base req of future games/dxvk/whatever releases and pipelines will just go away or stop being used
00:24 fdobridge: <k​arolherbst🐧🦀> doesn't sound like _anybody_ actually wants to use them
00:27 fdobridge: <R​hedox> as far as I know philip isn't interested in implementing shader objects in DXVK
00:28 fdobridge: <k​arolherbst🐧🦀> why not?
00:28 fdobridge: <R​hedox> graphics pipeline libaries work pretty damn well already
00:28 fdobridge: <k​arolherbst🐧🦀> doesn't it match d3d better even?
00:28 fdobridge: <R​hedox> it does
00:28 fdobridge: <R​hedox> you'd have to ask him for the exact reasons, probably just that it's a bunch of work for little gain
00:29 fdobridge: <R​hedox> + especially because RADV only just got GPL by default
00:29 fdobridge: <R​hedox> tess & geometry shaders are rare enough for those to not be a major concern
00:30 fdobridge: <k​arolherbst🐧🦀> mhh
00:31 fdobridge: <k​arolherbst🐧🦀> I mean sure, but maintaining multiple code paths
00:31 fdobridge: <R​hedox> but having shader objects will probably make implementing graphics pipeline libs pretty trivial for drivers
00:31 fdobridge: <k​arolherbst🐧🦀> also I'm sure that shader objects might just drop enough code so it might even reduce overhead
00:31 fdobridge: <k​arolherbst🐧🦀> drivers can just do driver optimized things
00:31 fdobridge: <k​arolherbst🐧🦀> well
00:32 fdobridge: <k​arolherbst🐧🦀> the issue is, that for most drivers, shader objects are pain 😄
00:32 fdobridge: <R​hedox> yeah IMO graphics pipeline libraries are the nicer solution to the same problem
00:32 fdobridge: <R​hedox> but I'm not a driver dev, so you definitely know better than me
00:33 fdobridge: <g​fxstrand> Yup
00:34 fdobridge: <k​arolherbst🐧🦀> mhhh
00:34 fdobridge: <k​arolherbst🐧🦀> not sure, every time @gfxstrand talks about GPL it sounded like it's the worst thing on earth
00:34 fdobridge: <g​fxstrand> That's exactly the concern as I understand it. They already have the old-school pipelines path and the GPL path, why add a 3rd?
00:34 fdobridge: <g​fxstrand> It is but it's also a sunk cost
00:35 fdobridge: <k​arolherbst🐧🦀> 😄
00:35 fdobridge: <k​arolherbst🐧🦀> fair enough
00:35 fdobridge: <R​hedox> whats your problem with GPL?
00:35 fdobridge: <k​arolherbst🐧🦀> yeah I mean.. I totally see that older projects might just keep whatever they have
00:38 fdobridge: <g​fxstrand> The way it carves state into 4 groups, while logical on the surface, is a massive pain to implement.
00:39 fdobridge: <g​fxstrand> The carve-up is not at all along input struct lines. It's all over the map. Bits of this here, bits of that there. If you accidentally grab the wrong state based on the wrong grouping, you're sunk.
00:39 fdobridge: <g​fxstrand> It's bad.
00:39 fdobridge: <g​fxstrand> I firmly believe there are zero correct implementations.
00:39 fdobridge: <g​fxstrand> And that if there are more than zero, they are all mesa
00:40 fdobridge: <R​hedox> nice, so there's 2 bad solutions to the pipeline compilation problem now 🙃
00:40 fdobridge: <R​hedox> and classic monolithic pipelines
00:41 fdobridge: <g​fxstrand> Speaking of... I should review @zmike 's MR for that mess.
00:42 fdobridge: <z​mike> wtf don't ping me unless memes are involved
00:44 fdobridge: <a​irlied> Isn't pinging you a meme of itself?
00:45 fdobridge: <k​arolherbst🐧🦀> 2 bad solutions?
00:45 fdobridge: <k​arolherbst🐧🦀> why would shader objects be bad
00:45 fdobridge: <k​arolherbst🐧🦀> it's just the hardware which doesn't match 🙃
00:45 fdobridge: <R​hedox> arent they a massive PITA for some drivers?
00:45 fdobridge: <k​arolherbst🐧🦀> so?
00:45 fdobridge: <k​arolherbst🐧🦀> they designed hardware around GL for years
00:45 fdobridge: <k​arolherbst🐧🦀> kinda their fault if you ask me
00:45 fdobridge: <k​arolherbst🐧🦀> that's what we had for 20 years
00:46 fdobridge: <k​arolherbst🐧🦀> well.. maybe 15
00:46 fdobridge: <k​arolherbst🐧🦀> pipelines only exist because they kept doing it and then developers said it sucks
00:46 fdobridge: <k​arolherbst🐧🦀> not sure if I'm missing something here, but that's more or less the tldr, no?
00:47 fdobridge: <k​arolherbst🐧🦀> I don't know if they had _good_ reasons for doing that, but it appears like Nvidia was fine with doing shader objects in hardware since forever
00:47 fdobridge: <z​mike> https://cdn.discordapp.com/attachments/1034184951790305330/1098771908033515630/7ixhre.png
00:47 fdobridge: <k​arolherbst🐧🦀> I really kinda want to know why all the other hardware was designed like that honestly
00:48 fdobridge: <z​mike> bEcAuSe PiPeLiNeS aRe So MuCh FaStEr
00:48 fdobridge: <k​arolherbst🐧🦀> yeah well..
00:48 fdobridge: <k​arolherbst🐧🦀> that's why nvidia is still the ones leading 🙃
00:50 fdobridge: <k​arolherbst🐧🦀> I dunno, maybe it simplifies hardware design or something
00:50 fdobridge: <k​arolherbst🐧🦀> or maybe it's a patent and nvidia refuses to give it away for cheap
00:51 fdobridge: <g​fxstrand> No
00:52 fdobridge: <g​fxstrand> For AMD and Intel, it's not THAT much work.
00:52 fdobridge: <g​fxstrand> AMD is worse than Intel but Intel is mostly sorted at this point.
00:57 fdobridge: <g​fxstrand> Quallcom is alright too, I think.
00:58 fdobridge: <g​fxstrand> It's really Arm and IMG which are horrible because they don't actually have tessellation or geometry shaders so they have to compile the entire geometry pipe into a single compute shader.
00:58 fdobridge: <k​arolherbst🐧🦀> mhhh, right ... that hardware
03:07 fdobridge: <g​fxstrand> `Pass: 278884, Fail: 6759, Crash: 19173, Skip: 1678761, Timeout: 32, Missing: 2566, Flake: 236, Duration: 1:47:59`
03:07 fdobridge: <g​fxstrand> I fixed bugs and things are worse. Oh, well, that's early compiler development for you, I guess. 🙄
03:07 fdobridge: <🌺​ ¿butterflies? 🌸> Yes this is alright for Adreno AFAIK
03:08 fdobridge: <🌺​ ¿butterflies? 🌸> Arm GPUs suck.
03:08 fdobridge: <🌺​ ¿butterflies? 🌸> They always did
06:52 fdobridge: <B​yLaws> I feel like just not supporting geom shaders with shader obj on these platforms is a reasonable decision
06:52 fdobridge: <B​yLaws> As opposed to not supporting it at all
06:52 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Just like NVK in the early days (but NVIDIA actually does support those shaders)
07:54 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> Still no fixup patch in mctestface 🐸
19:36 raket: DodoGTA: i applied the patches in the dxvk issue tracker, still getting the pusbuf thing. -> eso64.exe[7832]: pushbuf bo count exceeds limit: 1040 max 1024 ;)
19:37 raket: and used dxvk-1.5.1
19:38 fdobridge: <g​fxstrand> `Pass: 290588, Fail: 7207, Crash: 15312, Skip: 1672380, Timeout: 32, Missing: 671, Flake: 221, Duration: 1:33:49`
19:40 fdobridge: <M​ohamexiety> that's NAK?
19:40 fdobridge: <M​ohamexiety> niiice! \o/
19:42 fdobridge: <g​fxstrand> Yup. Slowly making progress
19:44 fdobridge: <W​aelUnix> blazingly fast 🐸
19:45 fdobridge: <W​aelUnix> does dxvk run on the nak branch or is still regular nvk
19:45 fdobridge: <W​aelUnix> does dxvk run on the nak branch or is it just nvk for now (edited)
19:45 fdobridge: <!​[NVK Whacker] Echo (she) 🇱🇹> I don't think vkcube even works on NAK (for now)
19:45 raket: asking me? i use nvk :)
19:46 DodoGTA: raket: I think you have to wait for the new uAPI for your issue to be solved
20:23 raket: DodoGTA: Oki! Thanks :)
20:46 fdobridge: <g​fxstrand> @Mr Fall🐧 Are there extra alignment requirements on jumps?
20:46 fdobridge: <g​fxstrand> Like, do they have to be aligned to 2 instructions or something?
22:11 fdobridge: <k​arolherbst🐧🦀> not as far as I know
22:11 fdobridge: <k​arolherbst🐧🦀> running into any issues with it?
22:13 fdobridge: <k​arolherbst🐧🦀> all jumps work based on addresses tho
23:51 fdobridge: <m​henning> one of the microbenchmarking articles I've read said that unaligned jump targets can be slower than aligned on some archs (but they should work)
23:52 fdobridge: <k​arolherbst🐧🦀> yeah, I guess blocks of 4 in maxwell+ no?
23:52 fdobridge: <k​arolherbst🐧🦀> maybe even 8... dunno
23:54 fdobridge: <m​henning> it was something like "align loop heads to the top of a scheduling info block for best perf". might have been as old as kepler
23:54 fdobridge: <k​arolherbst🐧🦀> right.. but that doesn't exist in volta+ anymore
23:54 fdobridge: <k​arolherbst🐧🦀> it's per instruction now
23:54 fdobridge: <k​arolherbst🐧🦀> or rather part of each instruction in the highest 25? bits
23:55 fdobridge: <m​henning> yeah, might be different on more modern archs
23:55 fdobridge: <k​arolherbst🐧🦀> maybe Faith got the sched info wrong 🙃
23:56 fdobridge: <k​arolherbst🐧🦀> but hard to tell without knowing what's wrong
23:56 fdobridge: <k​arolherbst🐧🦀> anyway: sched info has to consider _all_ branches
23:59 fdobridge: <k​arolherbst🐧🦀> which is slightly more annoying if you have instructions in the mix waiting on barriers