00:35 karolherbst: mhh
00:35 karolherbst: this fails: glTexImage1D(GL_TEXTURE_1D, 0, GL_R32UI, TEX_WIDTH, 0, GL_RED_INTEGER, GL_UNSIGNED_INT, data)
00:36 imirkin: karolherbst: GL or GLES?
00:36 karolherbst: GL
00:36 karolherbst: core even
00:37 imirkin: what's the failure?
00:37 imirkin: and with nvidia, or with mesa?
00:37 karolherbst: nvidia
00:37 imirkin: pastebin the program?
00:38 imirkin: if the image was created with glTexStorage you can't run glTexImage on it
00:38 karolherbst: uhm.. wait.. soemthing weird is happening actually
00:39 karolherbst: ohh.. false alarm I think
00:41 karolherbst: imirkin: anyway, that's my current version: https://gist.githubusercontent.com/karolherbst/2b19b5cb1346c23bea4d17358a1c40c5/raw/c9dd8f34797f85d4532a6366358ad52b92f6898d/test.c
00:41 karolherbst: inside run_test
00:41 karolherbst: the executed shader doesn't seem to affect the read out texture
00:42 karolherbst: trying to put some piglit_check_gl_error(GL_NO_ERROR) around
00:43 imirkin: i remember that test...
00:44 imirkin: right, so it doesn't check the return value of the atomic ops
00:44 imirkin: it only checks that the buffer is updated correctly
00:44 karolherbst: yeah.. but
00:44 karolherbst: with nvidia not even that happens
00:44 karolherbst: there were some issues I already fixed
00:44 karolherbst: like nvidia didn't like signed images and stuff
00:45 imirkin: in all cases, imageAtomic* is supposed to return the value that was read in
00:45 karolherbst: uhhh... I have a bad feeling..
00:45 imirkin: yes
00:45 karolherbst: could it be that not writing into the out color could mess things up?
00:45 imirkin: These functions support only 32-bit unsigned integer
00:45 imirkin: operands.
00:46 imirkin: i think this should only work r32ui
00:46 karolherbst: yeah
00:46 imirkin: does it work with r32i on mesa?
00:46 karolherbst: that's what I ported to, no?
00:46 karolherbst: yes
00:46 karolherbst: mesa is happy with r32i
00:46 imirkin: it shouldn't, i think
00:46 karolherbst: right
00:46 imirkin: ok, so that's a bug.
00:47 imirkin: will you be making a patch?
00:47 karolherbst: sure
00:47 imirkin: IncWrap/DecWrap are the only two which are unsigned-only
00:47 karolherbst: but first I want to fix the piglit test :p
00:47 imirkin: the rest of them are both
00:47 imirkin: sure.
00:47 karolherbst: I am not even sure that _we_ implemented it correctly
00:47 karolherbst: so I wanted to check with nvidia
00:47 imirkin: well, the test seems pretty clearly right
00:48 karolherbst: well
00:48 karolherbst: I changed it :p
00:48 imirkin: those compute_imageAtomciDecWrap / etc functions
00:48 karolherbst: imirkin: do you think compute_imageAtomicDecWrap is correct or not?
00:48 imirkin: seem like they should do the right thing in terms of emulating the shader?
00:49 imirkin: seems correct
00:49 karolherbst: it was "value = wrap;" before ;)
00:49 imirkin: at least assuming the quote is accurate relative to the spec
00:49 imirkin: the code seems to be doing what the logic says
00:49 imirkin: otoh it could all end up as 0 or something lame like that
00:49 imirkin: and so we wouldn't detect errors
00:50 karolherbst: nope
00:50 karolherbst: I put a memset in
00:50 karolherbst: essentially the shader doens't change the image
00:50 imirkin: and changed the starting value presumably?
00:50 karolherbst: even the imageStore has 0 effect
00:50 imirkin: (in the emulating logic)
00:50 imirkin: with nvidia or nouveau?
00:50 imirkin: (or both)
00:50 karolherbst: nvidia
00:50 imirkin: hmmmm
00:50 karolherbst: with mesa it "works"
00:50 karolherbst: yeah...
00:50 imirkin: could be a shader barrier missing
00:51 karolherbst: or not output written
00:51 karolherbst: *no
00:51 imirkin: that'd be a bug in their thing, but sure
00:51 imirkin: that can *esp* happen with GL_ARB_framebuffer_no_attachments...
00:52 karolherbst: yeah.. doesn't change anything
00:52 karolherbst: mhh
00:55 karolherbst: already wondering if I should just fetch a generated test and mess that up...
01:01 karolherbst: imirkin: I think something is busted
01:02 karolherbst: other tests are also simply failing
01:02 karolherbst: well.. only the image ones
01:17 imirkin: ok
01:18 imirkin: well, nvidia driver is the definition of correct
01:18 imirkin: so tests must be wrong
01:19 karolherbst: can't we do 1D images in shader_test files?
01:19 imirkin: dunno
01:19 imirkin: it's a bit of a pain to do images with shader runner
01:19 karolherbst: yeah.. I noticed
01:20 karolherbst: actually.. why 1D
01:20 karolherbst: I should be able to use 2D images with IncWrap just fine..
01:20 imirkin: sure
01:26 karolherbst: ahhh...
01:38 robclark: meson-windows CI job seems to be in bad state.. can someone disable? https://gitlab.freedesktop.org/robclark/mesa/-/jobs/3160491
01:40 airlied: robclark: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5534
01:40 robclark: oh, thx
01:41 robclark: btw, is it just me, or is marge not fifo? I guess I should wait until that gets thru marge's queue before re-assigning other mr
01:42 airlied: not sure that's even assigned to marge
01:42 robclark: (it kinda seems like she takes the lowest #'d MR first, regardless of order assigned)
01:42 robclark: I just assigned it
01:42 airlied: oh you just did
01:42 airlied: ah yes I do believe it's fifo
01:43 robclark: I could be wrong, because limited data set.. but when assigning multiple things it seemed like she took them in opposite order
08:11 MrCooper: robclark: that's correct, Marge currently processes her queue in ascending order of MR creation time; https://gitlab.freedesktop.org/freedesktop/helm-gitlab-config/-/merge_requests/18 would change that to the order in which they were last updated
08:24 daniels: *has changed that
09:21 MrCooper: kusma: please don't push directly to the main mesa repository
09:21 ccr: "that's a paddlin'"
09:25 kusma: MrCooper: Yes, that was a mistake. Terribly sorry, making sure my origin is no longer writable here.
09:27 daniels: should we just push the big red button and make it so only marge can push to master?
09:28 MrCooper: kusma: yeah, I've done the same (actually I changed origin to point to my personal repo, and am using https:// for the upstream remote, so pushing there would fail)
09:28 kusma: MrCooper: yeah, I already did that on my other machines ;-)
09:29 HdkR: This discussion made me search around and I like someone's answer that I may use myself `git config remote.origin.pushurl "you really didn't want to do that"`
09:29 MrCooper: daniels: my proposal would be restricting the whole main repo to owners & maintainers; either way though, this should probably be discussed on the ML first
09:30 daniels: sure
09:30 kusma: MrCooper: yes, I think that's a good idea.
09:31 kusma: The fewer ways I can shoot myself in the foot, the better :)
09:32 kusma: All I really want, is the ability to add tags and assign to marge ;)
11:10 K900: Hey guys
11:11 K900: Possibly weird question: I'm trying to reverse engineer the RGB lighting controls on my AMD Vega card, it's an I2C bus, and it seems like amdgpu does not expose it to /dev/i2c-*
11:11 K900: Is there any other way to read/write I2C stuff, or maybe to make amdgpu expose it?
11:12 K900: I'm not too familiar with the code, but I've looked at it a bit and I don't really see it filtering anything
11:30 malice: K900: What card
11:40 K900: malice: Sapphire Vega 56 Nitro+
11:41 K900: The RGB controller is supposed to be on bus 7, but amdgpu only exposes 0 to 5
11:43 karolherbst: imirkin: fixed it with a GL_FRAMEBUFFER...
12:06 K900: Sorry, IRC keeps disconnecting
12:14 karolherbst: pepp, imirkin: sooo.. either the spec is broken or nvidias implementation is broken :p
12:15 pepp: karolherbst: the piglit test is correct (according to the spec) but fails on nvidia?
12:15 karolherbst: both operations actually
12:15 karolherbst: pepp: the test is not correct either
12:15 pepp: ah :-/
12:15 karolherbst: compute_imageAtomicDecWrap didn't do what the spec was saying
12:16 karolherbst: but yeah..
12:16 karolherbst: it's a mess
12:16 karolherbst: pepp: this passes on nvidia: https://gist.githubusercontent.com/karolherbst/43c83b8b1489397383bbf2bcc0ec93ca/raw/09d50aeef8a421e5c874208e690e9dca6f645390/gistfile1.txt
12:16 karolherbst: tried different values even
12:18 karolherbst: nvidia also only executes the shader TEX_WIDTH times
12:18 K900: I'm trying to dig through the kernel now but all I'm finding is atombios stuff that doesn't seem to be meaningfully documented anywhere :(
12:18 karolherbst: I think somebody with a proper undertanding of GL needs to write a new test :p
12:19 karolherbst: pepp: maybe I am wrong, but I think compute_imageAtomicIncWrap and compute_imageAtomicDecWrap don't do what the spec is saying
12:19 karolherbst: _but_ they seem to reflect what Nvidia is doing
12:21 karolherbst: I am inclined to remove support for that or model it after nvidias use completly
12:21 karolherbst: but.. this is also no way people can even rely on what the spec is saying
12:31 pepp: karolherbst: the original compute_imageAtomicDecWrap is bogus indeed. "value = wrap;" should be "value = wrap - 1;". But the added compute_imageAtomicIncWrap seems wrong too
12:32 karolherbst: pepp: yeah, but that's what reflects nvidias implementation
12:32 karolherbst: so.. the problem now is, if somebody uses that extension, they tested against nvidia
12:32 karolherbst: so either we are compliant and break applications or we are non compliant and applications work
12:33 karolherbst: or we remove support for that alltogether as our implementation is too relaxed anyway
12:33 karolherbst: like nvidia rejects signed use of it, we don't
12:33 karolherbst: so if somebody deveops against mesa, it might not work on nvidia anyway
12:38 pepp: the signed/unsigned issue could be fixed easily I think
12:38 karolherbst: yeah..
12:39 karolherbst: just.. how much do we care implementing somethign which is obviously broken
12:39 karolherbst: and doing something different than nvidia probably causes more pain
12:40 karolherbst: if there are applications using this.. sure, fine, but if we are not aware of any, why risking this?
12:41 pepp: I think specperf does use part of the spec (the layout qualifier)
12:42 karolherbst: mhh.. yeah well.. we could leave that in even though it's a bit ugly.. but at least shouldn't cause any harm
12:42 karolherbst: I am more concerned about those broken atomics
12:45 pepp: did this happen before? (inconsistencies between the spec and nvidia implementation)
12:45 karolherbst: imirkin would know, but I think so.. yes
12:45 karolherbst: and people tend to follow nvidias interpretations
12:47 pepp: following nvidias implementation for a rarely used feature seems ok to me
12:53 karolherbst: pepp: yeah.. but I think for that we simply need to remove this add -1 hack
12:55 karolherbst: pepp: what annoys me more though is that the test of right now doesn't work on nvidia at all.. and once I made it work, it didn't work on mesa :/
12:55 karolherbst: so I am kind of inclined to not care as much until this gets resolved and my knowledge about GL is quite limited so I wouldn't even know what is a "correct" implementation here
12:56 karolherbst: maybe we should just use compute shaders though? dunno
13:00 bbrezillon: mattst88, jekstrand: I'm looking at supporting i64tofp32 natively because we need if for CLonD3D12, and I was wondering if there's any plan to progressively get rid of the GLSL implementations (float64.glsl) that's used by those calling nir_lower_doubles() in favor of native NIR lowering, or if you want to keep it like that
13:01 bbrezillon: mattst88, jekstrand: I already implemented this lowering pass, the question is, should I move it to nir_lower_double_ops.c or should I keep it as a driver-specific lowering pass
13:01 bbrezillon: ?
13:23 agd5f_: K900: the SMU generally controls the RGBs. There's an SMU message to enable/disable them
13:28 imirkin: pepp: karolherbst: the spec is quite clear that those don't work with signed, so we should definitely just fix that
13:31 imirkin: so it sounds like nvidia implemented it without the -1 that mesa throws in, right?
13:32 imirkin: i believe the best course of action is to reach out to the spec authors
13:32 imirkin: i haven't checked who it is, but on average those folks are moderately responsive
14:05 seanpaul: danvet, airlied: any feedback on the drm trace set?
15:18 danvet: seanpaul, entirely cache evicted from my brain :-/
15:18 danvet: wasn't I largely in agreement already?
15:19 seanpaul: danvet: yeah, i think it ticks all the boxes of interested parties
15:24 karolherbst: imirkin: yeah
15:24 karolherbst: so removing the -1 would make it compatible afaik
15:24 karolherbst: and it would make sense
15:38 jekstrand: bbrezillon: Uh...
15:38 jekstrand: bbrezillon: We'd love to get to a solution that doesn't require the GLSL compiler. The question is how.
15:39 jekstrand: bbrezillon: One thought that's occurred to me would be to steal the NIR -> SPIR-V compiler from Zink and build a GLSL -> SPIR-V compiler as part of the build process, use that to compile the GLSL to SPIR-V, and embed that.
15:39 jekstrand: bbrezillon: The real problem is that fp64 lowering is complex and doing it all in nir_builder is a good recipe for having write-only code.
15:42 jekstrand: bbrezillon: I'd be very happy to see a good solution here. We need something better than what we have today; specifically something that doesn't require loading GLSL IR.
15:42 jekstrand: Either that or a massively cleaned up GLSL compiler that can reasonably be built into a CL driver but that seems like it's going the wrong direction.
15:43 jenatali_: Couldn't we run the GLSL compiler during the build and just embed serialized NIR rather than SPIR-V?
15:44 jekstrand: Possibly.
15:45 jekstrand: There are some fun issues in there if you build on little-endian for big-endian or vice versa.
15:45 jekstrand: Currently, the serialization stuff doesn't handle byte order at all
15:45 jenatali_: Ooh... that's a fun problem I haven't thought about in a long time
15:45 jekstrand: We could just ignore the existance of big-endian
15:46 jekstrand: SPIR-V, in theory, should solve ths problem
15:46 jekstrand: though I don't know that we've ever run our SPIR-V parser on a big-endian system.
15:46 jekstrand: I may be just over-worrying. :-)
15:47 bbrezillon: jekstrand: ok, so re-implementing in NIR is not the right solution
15:47 jekstrand: bbrezillon: Probably not
15:48 bbrezillon: I wish I had asked before spending time on https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/148/diffs?commit_id=c11930b99864a2c451ac17353307fe3c1538d5cb
15:48 bbrezillon: :-(
15:49 jekstrand: nir_builder is nice but it's still more clumsy than I think we want to use for this.
15:49 jekstrand: In switfshader, they've got a nifty thing where you can basically write shaders in C++. Lots of horrible operator overloading and things to turn C++ into basically a builder.
15:49 jekstrand: It's kind-of crazy and kind-of great.
15:49 jekstrand: And definitely terrifying
15:49 bbrezillon: :)
15:55 daniels: so you're saying that we should have some kind of domain-specific language for writing shaders in? nice idea, but not sure if it'll ever catch on
15:55 jenatali_: jekstrand: Out of curiosity, what big-endian systems does Mesa actually support?
16:00 daniels: jenatali_: AMD + PPC64 is the classic
16:00 karolherbst: AMD?
16:01 karolherbst: bbrezillon: uff.. conversion stuff.. ufff
16:01 karolherbst: don't remind me :D
16:01 daniels: well, that's the one that always breaks :P
16:01 daniels: karolherbst: I've got a downstream MR you're really going to hate for conversion ... just need to rebase all the llvmpipe + CLC branches to test it on master
16:01 jekstrand: That's the one that breaks *and* there are people who complain about it. :)
16:02 karolherbst: daniels: I know
16:02 karolherbst: I hate everything conversion related :p
16:03 karolherbst: I gave up as constant folding is just super annoying
16:03 karolherbst: well.. with CL conversions
16:05 jenatali_: That reminds me, I should start sending more CL patches upstream...
16:05 karolherbst: happy to review them :p
16:05 karolherbst: now I got more time again
16:05 karolherbst: jenatali_: btw.. anything you are blocked on and I can take a look at?
16:06 jenatali_: There's still an outstanding image one targeting upstream, though it needs a fix I just found recently
16:06 karolherbst: ahh okay
16:06 jenatali_: karolherbst: Nah, things are looking pretty good :)
16:06 karolherbst: yeah. that was the one I was aware of, just curious if ther eis more
16:06 karolherbst: k, cool
16:06 jenatali_: Nope, but I've got plenty more that need to be made
16:06 karolherbst: still need to convince all of you to write a new OpenCL gallium frontend :p but I think I need to give up on that :D
16:07 jenatali_: At this point yeah I think we're a bit invested the dedicated CLOn12 runtime
16:08 jenatali_: Starting to get pretty good CTS pass rates too
16:08 daniels: I'm sure there's code we could stick into a src/opencl/ from the Mesa tree
16:09 daniels: particularly the SPIR mangler as a start
16:09 karolherbst: spir mangler?
16:09 daniels: mangle function names for type overloading
16:09 karolherbst: ahh, yeah
16:09 daniels: the LLVM one didn't actually handle everything so we ended up just writing our own
16:09 karolherbst: fair enough
16:10 daniels: which tbh is barely more code than translating between NIR & LLVM
16:10 jenatali_: Might actually be less...
16:11 daniels: certainly less if you consider not having to track API changes
16:11 karolherbst: oh, so it targets llvm? mhhhh
16:11 daniels: hm? no
16:12 karolherbst: ohh, okay
16:12 daniels: we use Clang to compile CL C -> SPV
16:12 daniels: but every CL built-in function should have its name mangled to account for operator overloading
16:13 karolherbst: right..
16:13 daniels: e.g. append Dv2_f for one float2 arg
16:13 daniels: we used to call into LLVM to do that mangling for us; now we don't
16:13 karolherbst: mhh. I think I remembered some comments on the libclc MR on that
16:14 jenatali_: Specifically so that we could translate SPIR-V opcodes into libclc functions
16:14 tango_: shouldn't mangling prepend __ to avoid potential conflict with other user-defined names?
16:14 daniels: our backend generates LLVM bitcode, but it does that by hand because it's a derivative of LLVM3.7 bitcode
16:14 daniels: tango_: no
16:14 daniels: the builtins are reserved for the implementation, per spec
16:14 tango_: the built-ins yes
16:14 tango_: but the mangled names no
16:14 tango_: so e.g. if you have cos() and mangle it to cos<stuff_based_on_args> you may conflict
16:14 daniels: a user cannot define a function called asinf
16:15 jenatali_: tango_: Technically the mangling also prepends _Z
16:15 tango_: ok
16:22 daniels: yeah, _Z{namelen}
19:16 eric_engestrom: since people are talking about C++ symbols, does anyone know how to avoid exporting random symbols whenever we link any .cpp in a lib?
19:16 eric_engestrom: (see https://gitlab.freedesktop.org/mesa/mesa/-/issues/1939)
19:22 ajax: which lib in particular?
19:22 eric_engestrom: iirc all of the ones that have a .cpp file
19:23 pcercuei: eric_engestrom: add -fvisibility=hidden to the compilation flags, and explicitely export the symbols you want using __attribute__((visibility ("default")))
19:25 ajax: the gallium_dri.so i happen to have just built exports no symbols matching _Z*
19:25 ajax: and definitely compiled src/gallium/auxiliary/tesselator/tesselator.cpp
19:25 ajax: so... more specific please?
19:26 ajax:adds some more drivers
19:27 jenatali_: eric_engestrom: In addition to -fvisibility, there's also --exclude-libs on the linker command line to prevent a lib from providing any exported symbol
19:35 eric_engestrom: ajax: yeah, I can't reproduce the issue on my machine either, but the CI pretty much always does
19:35 eric_engestrom: or *did* last year
19:35 ajax: so... gcc bug?
19:35 eric_engestrom: possibly?
19:36 ajax: i'd definitely hit some weird cases years ago where gcc would just emit symbols at default visibility for no obvious reason
19:36 eric_engestrom: or a different configuration?
19:37 ajax: if all else fails there's always objcopy -L
19:37 ajax: but i'd just drop that _Z special case and see who complains, because it _probably_ means their toolchain is busted
19:38 eric_engestrom: my issue was mostly about being able to verify in the CI that we don't export anything we shouldn't
19:38 eric_engestrom: "i'd just drop that _Z special case" -> that would break the CI
19:39 ajax: fine, make me trigger a CI run with it turned off. i see how it is.
19:46 eric_engestrom: pcercuei, jenatali_: `--exclude-libs` would have to be `ALL`, as the symbols exported are `std::max()` and such, and I think we already use `-fvisibility=hidden` but these C++ symbols are exported regardless
19:47 eric_engestrom: I think I agree with ajax that this is probably a gcc bug, the more I think about it
19:47 eric_engestrom: we've probably upgraded gcc in the CI by now; ajax, did you do that run with the _Z line removed? otherwise I'll do one now to see if the issue is gone
19:49 ajax: eric_engestrom: just launched it
19:49 eric_engestrom: ack, thanks
19:50 eric_engestrom: "cxx-sucks" xD
19:50 eric_engestrom: https://gitlab.freedesktop.org/ajax/mesa/pipelines/163202 if anyone else want to see
19:51 ajax: https://gitlab.freedesktop.org/ajax/mesa/pipelines/163202
19:51 ajax: bah, beat me to it
19:51 ajax: i mean, it does.
19:53 eric_engestrom: true
19:56 ajax: hm. radv failed the symbol test.
19:56 eric_engestrom: nope, issue is still here
19:56 ajax:digs
19:56 eric_engestrom: https://gitlab.freedesktop.org/ajax/mesa/-/jobs/3179850#L2103
19:56 bnieuwenhuizen: ajax: what symbols?
19:56 eric_engestrom: bnieuwenhuizen: _ZSt3absl, _ZSt4fabsf, _ZSt5isnand, _ZSt5isnanf
19:56 eric_engestrom: see the list at the end of the last link
19:57 ajax: 00000000001eefb0 W std::_Rb_tree<unsigned int, std::pair<unsigned int const, unsigned int>, std::_Select1st<std::pair<unsigned int const, unsigned int> >, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, unsigned int> > >::_M_get_insert_unique_pos(unsigned int const&)
19:57 eric_engestrom: wait, anv exports these 4; radv exports about 50 of them
19:57 ajax: "and what do you call this act?" "templates!"
19:58 eric_engestrom: aka the main reason C++ sucks
19:59 ajax: naturally there are zero grep hits for _Rb_tree
20:04 jenatali_: _Rb_tree would probably be std::map's implementation class
20:04 ajax: ngh. definitely passing -fvisibility properly.
20:06 ajax: well. to the g++ -c phase, anyway. but you would really hope you wouldn't need it for the link phase.
20:08 jenatali_: I wonder if link-time codegen can generate new symbols? I'd hope not...
20:09 ajax: adding cpp_vis_args to the link_args for libvulkan_radeon does add -fvisibility to the link line, but does not change the result
20:10 ajax: so like... in principle there shouldn't be a problem, because while they're exported they're also weak, so if the app also provides the symbol then the strong definition should win out
20:11 ajax: but that's still stupid
20:13 ajax: seeing an awful lot of #pragma GCC visibility push("default") under /usr/include/c++/10 and i think this is where i'm likely to tag out
20:15 ajax: ugggggh
20:16 ajax: namespace std _GLIBCXX_VISIBILITY(default)
20:16 ajax: in bits/stl_tree.h which seems to be where class _Rb_tree is defined
20:17 jenatali_: Why...
20:18 ajax: good question, let's ask git-blame...
20:19 jenatali_: Personally I'd go with --exclude-libs=all and a version script to explicitly control the set of exports, but that's probably just because I'm coming from a Windows background where __declspec(export) or a .def file is needed to export
20:20 ajax: this is one of the few things windows got right, tbh
20:21 jenatali_: ELF can behave the same way, you've just gotta really try to force it to
20:21 ajax: elf's "sure just export everything, you definitely wanted runtime linking to be exactly like static linking" design decision was maybe tactically necessary but strategically boneheaded
20:24 ajax: so that particular line was last touched in 2011, where it was part of a rework of the namespace/visibility macros
20:25 ajax: which (if i'm staring at this magic eye diagram right) need to be conditionally defined based on whether you're doing debug or profiled or ...
20:25 jenatali_: Wow
20:25 ajax: and i now 101% do not want to look at this any further, but i would probably go ask my toolchain team what the actual eff
20:25 ajax: because that really does seem like an error
20:30 airlied: daniels: nice on mangler, that is an ugly piece of my clc pat hes
20:31 jenatali_: airlied: Ended up pretty simple actually: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/112/diffs?commit_id=76876778ad7f5f4891caf6e8ad1dee5a3bebc8da
20:43 ajax: so having trolled my toolchain team i was pointed at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022#c4
20:43 ajax: which does seem relevant, but also still insane
20:44 ajax: so i'm thinking teaching meson about objcopy might not be the worst plan, here
20:48 bnieuwenhuizen: ajax: the positive new is that a vulkan driver should export like exactly 3 functions, so if we have a place to hook in a linker script that might be doable?
20:52 ajax: i would hope it's easily doable - ld should treat input files in unknown formats as linker scripts so you'd hope it's just one more file on the link line - but i've not tried to convince meson to do that, myself
20:54 airlied: jenatali_: lols I'm embarressed that is smaller than calling out to llvm :-P
21:01 airlied: daniels, jenatali_, jekstrand : we could write float64 support in CLC and put in the CLC->SPIR-V library
21:02 airlied: or another libray like it
21:03 jekstrand: airlied: That's an option. I'd like to do something where we can have a single source file.
21:03 jekstrand: Maybe we can add some #defines so it compiles both ways?
21:06 airlied: I did refrain from saying we should call out to glslang to convert out glsl to spirv
21:11 jekstrand: airlied: I think if you paste the glsl standalone together with NIR and the Zink back-end, we could build our own SPIR-V compiler.
21:11 airlied: yeah at least enough of one to suffice for this
21:12 airlied: but yeah it does raise the do we generate it up front, at build time or at runtime
21:12 airlied: with all the ensuing cross compile and endianess fun
21:17 jekstrand: I'm not a fan of shipping GLSL in Vulkan
21:22 dschuermann: jekstrand: if you find time, could you have a second look if https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5207/diffs?commit_id=534a4aba9ac3d608ba29196aff80167b491f86a0 is fine now? it only flags variables now
21:34 jenatali_: airlied: Agreed with jekstrand, I'm fine with upfront or build time, but I think not at runtime
21:36 krh: we're building in the glsl compiler to avoid 50 lines of nir_builer?
21:36 jekstrand: No, to avoid a few thousand
21:36 jekstrand: where by "few" I mean more like 20-50
21:36 ajax: just give me a glsld already
21:36 krh: seems like we could write a python script to generate it
21:37 krh: I mean, I doubt it's going to be worse than nir algebraic
21:37 jekstrand: We can write nir_builder directly too
21:47 mattst88: the glsl float64 code that we compile at runtime is gross, but think it's necessary (as opposed to accidental) grossness
21:48 mattst88: and at least for intel, the time spent compiling any shaders that need it is overwhelmingly spent in the backend, rather than in any part of the compiler further up in the stack
21:48 jekstrand: Yeah, I've yet to see a better plan. :-(
21:48 imirkin: didn't idr have some sort of glsl -> glsl builder converter?
21:48 jekstrand: Yes
21:49 jekstrand: But that doesn't solve the above problem.
21:49 mattst88: and that seems unavoidable and wouldn't be fixed by changing the input language
21:49 jekstrand: The problem being discussed is how to do fp64 lowering in non-GL drivers.
21:49 imirkin: you could just run it once for each function
21:49 imirkin: and save off the nir for it
21:49 jekstrand: imirkin: That's what we do, at runtime the first time we encounter fp64.
21:49 mattst88: also: the bootstrap-the-compiler to build the compiler strategy we used for built-in glsl functions was fucking terrible
21:49 imirkin: right, but i mean you could do that offline
21:49 imirkin: e.g. as part of the build
21:50 mattst88: imirkin: sure, but there's almost not cost to that part of the process
21:50 imirkin: but then you wouldn't have to bundle glsl for a non-GL driver
21:50 mattst88: oh, I see
21:50 imirkin: which i understood was the problem at hand
21:50 mattst88: I haven't read the backlog, sorry.
21:51 imirkin: if the problem at hand is "fp64 sucks when it's not in hardware", i don't know that there's a solution to that problem
21:51 mattst88: right
21:51 jekstrand: :P
21:51 jekstrand: Yeah, people want fp64 lowering in their CL stacks.
21:51 jekstrand: And I've mentally toyed with the notion of enabling it for ANV.
21:51 jekstrand: And then immediately thrown the toys away. :P
21:52 jenatali_: Our problem isn't actually fp64, doubles are optional in CL and we can just not support them
21:52 mattst88: cool, that was my next question
21:52 jenatali_: int64 isn't optional, and int64 -> float32 is what we need
21:52 mattst88: makes sense
21:53 jekstrand: jenatali_: Wait, we don't have lowing for that? I was sure we did.
21:53 jenatali_: jekstrand: No, I don't think so, it's in the float64 glsl
21:53 jekstrand: Oh
21:53 jekstrand: Yeah, We should have a version in lower_int64
21:53 krh: jekstrand: that's what bbrezillon wrote here: https://gitlab.freedesktop.org/kusma/mesa/-/merge_requests/148/diffs?commit_id=c11930b99864a2c451ac17353307fe3c1538d5cb
21:54 jenatali_: Yep, exactly
21:54 jekstrand: Yeah, we should just pull that into lower_int64
21:54 jekstrand: Sorry, I missed some context somewhere.
21:54 jekstrand: There's no fp64 involved there.
21:54 jenatali_: That was my thought as well
21:55 jekstrand: For that matter, that looks overly complicated
21:55 jekstrand: We should be able to a log2 to figure out how big it is, shift to fit in int32, make sure we round right, i32 -> f32 cast, and then multiply by a thing.
21:55 mattst88:https://media.giphy.com/media/4pMX5rJ4PYAEM/giphy.gif
21:55 jekstrand: Maybe it does that
21:56 jekstrand: But it looks at a glance like it's more instructions than needed.
21:57 jekstrand: Hrm.. Seems to roughly do that. It's just more instructions than I was expecting. :-/
21:57 jekstrand: Anyway, we should just add it to nir_lower_int64
21:58 jenatali_: jekstrand: Cool, thanks
22:01 eric_engestrom: ajax, jenatali_: just got back (and going to bed in a minute); reading the backlog, it looks like it's intentional to randomly export C++ symbols and we can't do anything about it?
22:01 eric_engestrom: (besides replacing symbols-check with a linker script)
22:03 jenatali_: I just opened that bugzilla entry... seems like the flaw here is allowing C++ exceptions to cross module boundaries