00:02 kode54: I am disappointed I can't test SotTR on Linux native
00:03 kode54: I got it free on Epic, so I only have a Windows port wrapped in wine
00:03 kode54: never bought the sequels because I bought the original and never finished it
00:11 alyssa: karolherbst: hmm ok
00:12 alyssa: karolherbst: per the pcgamingwiki
00:12 alyssa: deus ex: no vk, but d3d11/12 and opengl is "Linux only. Used to convert Direct3D 11 calls" so meh
00:12 karolherbst: yeah....
00:12 karolherbst: none of them were good ports
00:13 alyssa: dirt rally is unobtanium
00:13 karolherbst: but they are "native" and use tesselation and gl
00:13 karolherbst: alyssa: I wonder if you'd still get it through the feral Linux steam key thing
00:13 alyssa: can't find hitmanpro
00:14 karolherbst: alyssa: https://store.steampowered.com/app/236870/HITMAN/ probably
00:14 alyssa: shadow of mordor has a vulkan port, or d3d11
00:14 alyssa: hitman 2016 has a vulkan or d3d11/12
00:14 karolherbst: really?
00:14 karolherbst: it's like 8 years old
00:15 alyssa: tomb raider has d3d11 as well
00:15 karolherbst: ah yeah
00:15 alyssa: so for all of the above, "use dxvk + windows version" is an option
00:15 alyssa: which makes it hard to motivate speeding up the gl specific tess paths.... hmm....
00:15 karolherbst: probably the better option even
00:16 karolherbst: I remember that tomb raider was faster through wine 🙃
00:16 karolherbst: and I think in all those games tesselation is even optional
00:17 alyssa: fun
00:17 karolherbst: anyway, I'll doubt you'll find anything where tesselation is a hard req
00:17 karolherbst: at least with GL
00:18 alyssa: ack
00:18 alyssa: really hard to motivate GL-specific tess perf work then, heh
00:18 karolherbst: heh
00:18 karolherbst: I think stuff requiring geometry shaders is more likely, but also....
00:19 alyssa: we're shipping fast geometry shaders in the gl driver
00:19 alyssa: disturbingly
00:19 alyssa: (:
00:19 karolherbst: impressive
00:19 alyssa: (as in - significantly faster than what was presented at XDC. I got angry at a Citra apitrace. Citra renders everything with a GS. Everything.)
00:20 karolherbst: oof
00:20 karolherbst: why....
00:21 karolherbst: I'm kinda happy we have a competent vulkan driver in nouveau now, so I won't have to bother with GL 🙃
00:22 karolherbst: hopefully you'll get there as well
13:46 glehmann: does anyone know why NIR has separate opcodes with _flush_to_zero for unpack_half`? They are annoying because they tend to be forgotten all the time, I think having the normal unpack flush denorms depending on the float control mode would be better
13:46 glehmann: that's also how denorm flushing works for all other opcodes
13:48 glehmann: samuelig: cwabbott: seems like you added these opcodes in https://gitlab.freedesktop.org/mesa/mesa/-/commit/1e0e3ed15a8cfb98a182714bcb3e55cfab5c3df7, do you remember why you went with that solution?
13:50 karolherbst: glehmann: because you can specify rounding modes on some fp16 operations
13:50 karolherbst: in spirv
13:50 glehmann: that's for OpFConvert, and it's also about rounding not denorm mode
13:51 cwabbott: glehmann: because drivers like radv need a way to always get round-to-even
13:51 karolherbst: FPRoundingMode
13:51 cwabbott: for lowering FS outputs, iirc
13:51 karolherbst: "The FPRoundingMode decoration must be applied only to a width-only conversion instruction whose only uses are Object operands of OpStore instructions storing through a pointer to a 16-bit floating-point object in the StorageBuffer, PhysicalStorageBuffer, Uniform, or Output Storage Classes."
13:52 cwabbott: I think radv and radeonsi use pack_half internally when lowering FS outputs to exports
13:52 glehmann: again, this is not about rounding
13:52 glehmann: it's for flushing fp16 input denorms in unpack_half
13:52 karolherbst: ohh wait.. right, I misread that part...
13:53 karolherbst: but anyway, there are instructions in CL which always preserve, so we need something per instruction either way
13:53 cwabbott: ah right, denorms...
13:54 karolherbst: but I haven't enabled fp16 yet, but.. it's going to be annoying if we start to remove those things
13:54 cwabbott: radv might need to always preserve them when blitting
13:54 cwabbott: or rather when copying
13:54 cwabbott: I'm not sure how that works, though
13:54 karolherbst: yeah...
13:55 glehmann: radv handles unpack and unpack_flush_to_zero the same, what happens to denorms depends on the global mode
13:55 karolherbst: "Denormalized numbers for the half data type which may be generated when converting a float to a half using vstore_half and converting a half to a float using vload_half cannot be flushed to zero"
13:58 karolherbst: mhh
13:58 karolherbst: there is also OpQuantizeToF16
13:58 karolherbst: which must flush
13:59 karolherbst: so not really sure how we'd get away with only global modes in either case
14:00 karolherbst: though not sure if one needs those flush_to_zero things for that, but maybe?
14:01 karolherbst: looks like we have nir_op_fquantize2f16 for that one
14:22 glehmann: yeah quantize is something else
14:22 glehmann: I think there is no reason to keep the opcodes given what backend do with them: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29433
15:46 zmike: mattst88: did anything ever happen with that vkcts ticket someone made about runtimes and process zygoting?
15:46 zmike: I can't find the actual ticket
16:05 mattst88: zmike: not yet. the ticket is here -- https://gitlab.khronos.org/Tracker/vk-gl-cts/-/issues/5069
16:05 mattst88: rg3igalia said optimizing ::checkSupport didn't yield any improvements
16:06 rg3igalia: correct, I took an initial look at it following my instinct and checkSupport optimization proved unsuccessful
16:06 rg3igalia: zygote mode should be the next bet
16:06 zmike: would that be a deqp executable change?
16:07 rg3igalia: yes
16:08 zmike: hm
17:08 DavidHeidelberg: eric_engestrom: just disable LTO I stead of cutting whole job
17:08 DavidHeidelberg: *instead
20:27 DavidHeidelberg: anyone want to lay eye on some clarification and simplification on two remaining piglit tests I touched: https://gitlab.freedesktop.org/mesa/piglit/-/merge_requests/920 ?
20:59 Lynne: gfxstrand: any plans for descriptor_buffer in nvk? its currently the only major implementation that doesn't support running ffmpeg's filters
21:04 jenatali: FYI for folks here, we (Microsoft) just brought online a new Windows runner to add to the CI capacity for FDO. If you're seeing any problems with it please let me know :)
21:05 feaneron: nice
21:56 robbielex: you actually should not worry about you or me, I am mistaken a lot, still trying to climb higher but my bet it's possible and I am quite close, but it's a lot of brain bomb works needed yet, I am still bit afraid of landing dry, me there's not much to worry about the criminals finishing me like they tell on streets I am not afraid of that , but yes I design things around plus and minus
21:56 robbielex: cause they are somewhat natural on double compacting, just need to get the constants right, it's tough to everyone including me, trying the possible impossible:P but as things function ok, it's my eager temper and nature to try the least, so I am on such crazy things that I think that emulating 64 bits is possible on 16bit addon accelerator, I always have crazy seeming ideas and takes and
21:56 robbielex: attempts. I struggle with sleeping at times not cause I am embarrassed or afraid, but I have unresolved sources of pain and no discount in life it's physical but I try to solve those, and that's what I advise to you be fearless do not account with threats or criminals gangsta blabber, there's much bigger chance of asteroid hitting you or at least getting into car crash than such crap at
21:56 robbielex: least that's with me, I am not afraid of weird gangsta criminals.