01:52airlied: karolherbst: might needt o bounce that MR off marge-bot again
01:53karolherbst: honestly, this happend to me the third time in a row
01:53karolherbst: airlied: btw.. 5 CTS fails left if I ran it on the mustpass list :p piglit gives me 8 though
01:55airlied: karolherbst: nice!
01:57airlied: karolherbst: what's your cts fail list?
01:57airlied:is down to 1 or 2 now
01:58karolherbst: austriancoder_: https://gist.github.com/karolherbst/3f89839c4f7ba0ab85ec7d012be682ad
01:58karolherbst: airlied: the barrier one is probably super annoying to figure out
01:58karolherbst: the last two are just the CTS and mesa core being wrong :p
01:59airlied: karolherbst: btw be careful with glspirv
01:59airlied: the mesa code has some memory leaks
01:59karolherbst: it's a bug in the CTS :p
01:59airlied: KHR-GL46.direct_state_access.textures_parameter_setup_errors is my remaining one
01:59airlied: karolherbst: the mesa code also has some memory leaks :-P
01:59karolherbst: yeah.. wrong error code
02:00karolherbst: seemed non trivial to fix so I wait :p
02:00karolherbst: the spirv one is super annoying
02:00airlied: karolherbst: the gl spirv code in mesa had some rallocs that never got connected properly, asan complained a lot for me
02:00karolherbst: it requires 9 or 10 images in a compute shader
02:00karolherbst: we only support 8....
02:01airlied: I bailed on glspriv for now, as doing the full cts_runner run is quite sensitive to mem leaks
02:01karolherbst: yeah.. maybe I limit it to 4.5 for now as well as I am still worried about enabling nir for all gens
02:02karolherbst: there are just super annoying random fails on other gens
02:02karolherbst: oh well
02:02karolherbst: bed time :p
03:50airlied: karolherbst: do ypu pass all the GTF tests?
07:23airlied: karolherbst: the dsa test is wrong and mesa is wrong :-P
07:25airlied: karolherbst: will dig into a bit more tomorrow, as I think the spec changed, and the test is kinda wierd
07:27airlied: okay spec changed between 4.5 and 4.6 and tests bounced
09:13karolherbst: but I think I pass all gtf tests
09:13karolherbst: I just get some dmesg warning for one tfb test and now idea what's that all about
12:33bbrezillon: janesma: Hi! Is there anything I should do to have one of my branch hooked up to intel CI? I've created the branch daniels asked you to add, but I see nothing in https://mesa-ci.01.org/bbrezillon/builds/
12:50karolherbst: bbrezillon: you should get an email first anyway
12:58bbrezillon: karolherbst: then I confirm it's not been added :)
13:09bbrezillon: mattst88: any suggestion to replace the fdiv/frem here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588#note_557798 ?
13:11bbrezillon: mattst88: I'm also not sure what you meant here https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5588#note_556165.
13:31karolherbst: nice! managed to setup virtualgl to be able to do remote rendering :)
14:55robclark: does this mapi xml error ring a bell (hitting this on 20.1-branchpoint.. trying to bisect a thing)
14:57robclark: hmm, I guess 7a68045b is needed..
15:28eric_engestrom: robclark: yeah, was going to say you need 7a68045b
15:28eric_engestrom: the old/deprecated .getchildren() was dropped in python 3.9
15:29robclark: yup, that commit did the trick.. I just cherry-picked it after the branchpoint and rebased master for the purposes of bisecting..
15:53Lyude: is it me or is anongit.freedesktop.org down?
15:53imirkin: Lyude: cgit isn't working
15:53imirkin: (for me)
15:54imirkin: much sad.
15:54Lyude: daniels: btw ^
16:05eric_engestrom: MrCooper: I don't agree that the CI on stable branches is wasting resources
16:06eric_engestrom: even with some jobs not running for various reasons, the rest are still important and useful
16:14sravn: airlied: "drm/drm_fb_helper: fix fbdev with sparc64" - shall I read your feedback on mail as an a-b and then OK to commit to -fixes?
16:15sravn: I have locally fixed the sparse warning and updated the changelog as suggested by Mark
16:18eric_engestrom: dcbaker[m], SolarAquarion: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5882
16:18eric_engestrom: should fix it
16:19danvet: sravn, are all current fbdev helper uses using iomem for their real buffers?
16:19danvet: I think unconditional memcpy_toio can break on these
16:21eric_engestrom: MrCooper: about that "dri3 option "true" deprecated" message, I have a feeling running `meson --wipe` in your build dir might fix it
16:22danvet: sravn, typed up a longer reply on dri-devel
16:24daniels: Lyude: thanks, kicked it
16:24dcbaker[m]: eric_engestrom: r-b on that
16:26danvet: hwentlan, btw what's the dc take on Re: [PATCH 01/25] dma-fence: basic lockdep annotations?
16:27danvet: specifically Message-ID: <CAKMK7uHbS8-jXDhGnKaK_65Hs4EUrcfBUe-wcvfPt18weCN0hQ@mail.gmail.com>
16:37Lyude: daniels: seems like stuff is still down
16:38orbea: eric_engestrom: as discussed in #meson the other day the deprecated messages occur even with a clean git clone that has no previous builds.
16:39orbea: err #mesonbuild
16:39eric_engestrom: yeah, I just read that in the #mesonbuild backlog a minute ago ^^
16:39eric_engestrom: looking at this now
16:40eric_engestrom: that does sound like a bug in our meson.build
16:45dcbaker[m]: I think egl is buggy on our side, dri3 is a meson bug I think
16:46orbea: i saw it with several options *gets log*
16:49daniels: Lyude: yep, back now
16:50orbea: so at least 7 options have that issue
16:54orbea: also unrelated warnings, several of these: WARNING: custom_target 'glcpp-parse.[ch]' has more than one output! Using the first one.
16:54orbea: and: WARNING: Library target 'GLESv2' has 'name_prefix' set. Compilers may not find it from its '-lGLESv2' linker flag in the 'glesv2.pc' pkg-config file.
16:55eric_engestrom: I'm not seeing any of these true/enable warnings on meson 0.54.3
16:55eric_engestrom: I'll try 0.55 and master
16:55eric_engestrom: but I have a feeling it might be a meson bug
16:55orbea: i have the master as of yesterday installed now
16:59eric_engestrom: hmm, on master (sync'ed just now, 848fcb6a537d58cf5d49) I'm not seeing the true/enabled warnings either, but I am seeing the custom_target errors
17:00imirkin: daniels: thanks! at least cgit is happy now
17:00daniels: I'm not happy unless cgit is happy
17:00orbea: are you actually setting -Ddri3=true and such?
17:03Lyude: daniels: cool, thanks!
17:04eric_engestrom: orbea: ah no, I thought this was with the default options
17:04eric_engestrom: my bad, trying everything again
17:04orbea: and with -Ddri3=enabled it errors
17:06eric_engestrom: so, the fact you get a warning when you use `true`/`false` is normal, that's because you should be using `enabled`/`disabled`
17:06eric_engestrom: and I'm getting that
17:07eric_engestrom: but with `enabled` it doesn't print any warning or error for me on either 0.54.3 or master
17:07orbea: let me try again
17:08orbea: maybe only one of the options is erroring
17:08eric_engestrom: just tried 0.55.0 and I'm also seeing the expected behavious
17:08eric_engestrom: I tried setting `dri3`
17:12Lyude: mripard, mlankhorst - going to push https://patchwork.freedesktop.org/series/77670/ through intel-next, unless you think the drm core changes there warrant pushing to drm-misc-next for some reason
17:12Lyude: (cc j4ni ^ )
17:16orbea: eric_engestrom: wierd, I can't reproduce the error anymore.
17:16ccr: ~ magic ~
17:17orbea: and my old logs didn't say what option did it...
17:32orbea: eric_engestrom: okay I understand what happened now, I did -Dgallium-nine=enabled which unlike all the other options, only accepts true/false.
17:34orbea: other options in my build script*
17:40Lyude: (currently fixing the merge conflict on drm-tip, if anyone is wondering)
18:56eric_engestrom: orbea: ok, so no issue left then?
18:57eric_engestrom: (besides the custom_target warning)
19:16jekstrand: karolherbst, robclark, anholt__, Kayden, alyssa, and any other usual suspects: Any thoughts on the notion of supporting C-style builtins in NIR?
19:17jekstrand: My current thought is to have something that looks sort-of like a struct type only where the field offset is in bits starting from LSB
19:17jekstrand: And have some sort of notion of the "integer type" of the bitfield which whould be a UINTN_T
19:18bnieuwenhuizen: jekstrand: what do you mean C style builtins? wouldn't that fit intrinsics?
19:18karolherbst: I think he meant bitfields
19:19bnieuwenhuizen: uh yeah, that'd make sense
19:19robclark: ahh, s/builtins/bitfields/ makes *much* more sense.. I was having a hard time parsing that ;-)
19:19karolherbst: jekstrand: no idea.. would that gives us a real benefit besides packed structs?
19:19karolherbst: at least our alu is quite 32 bit and dealing with bitfields would mean a lot of lowering
19:20jekstrand: builtins? I mean bitfields.
19:21robclark: I guess a bitstruct type (with offsets in bits) sounds reasonable..
19:21robclark: but yeah, would need some lowering
19:21jekstrand: karolherbst: The idea is that it would lower to lots of bitfield_insert/extract before the driver sees it.
19:22karolherbst: I guess we'd need something for packed structs one way or the other and being more explicit about it might make a lot of things a lot easier
19:22bnieuwenhuizen: the question is what do we gain versus just building bitfield_insert/extract in the first place?
19:22jekstrand: bnieuwenhuizen: I'm honestly not sore
19:22jekstrand: Some amount of convenience
19:22jekstrand: But maybe it would lead to having to handle bitfields all sorts of places where we would rally rather not
19:22karolherbst: well, for CL it makes a lot of sense to have it...
19:23karolherbst: as I am sure you can have c style bitfields in CL
19:23bnieuwenhuizen: right, just wondering if it'd make sense to keep it in the SPIR-V parser
19:23jekstrand: Though I could see it being really nice if copy_prop_vars could handle bitfields
19:25jekstrand: Otherwise, if we want to copy-prop just 5 bits in the middle of a bitfield, we need potentially quite a bit of algebraic to see through all the insert/extract.
19:26jekstrand: That's my #1 rational
19:28karolherbst: jekstrand: ohh right, the nir opcodes we have are byte wise, aren't they?
19:28jekstrand: karolherbst: Yeah
19:28karolherbst: okay.. so yeah +1 on having bitwise variants :p
19:29jekstrand: karolherbst: So without a bitstruct type, you would see a pile of BFI to construct it and then a BFE to remove and we'd need some sort of algebraic pass capable of seeing through it all.
19:29karolherbst: we have to multiply by 8 in hw anyway
19:29karolherbst: so for us converting those to bit has 0 impact
19:29jekstrand: What do you mean?
19:29karolherbst: our instruction operate bitwise
19:30karolherbst: so bitfield_extract are two instructions
19:30karolherbst: one to convert the mask to byte
19:30karolherbst: and then do the extbf
19:31jekstrand: Yeah, same here
19:31karolherbst: (extbf src0 (insbf src2 0x808 src1))
19:31karolherbst: is what we do
19:32jekstrand: We have a BFM thing which takes the two parameters and creates a mask and then BFI takes the mask.
19:32jekstrand: I don't remember how extract works
19:32jekstrand: Or maybe that is how extract works?
19:32imirkin: dunno about the latest gens, but the earlier gens are a bit different
19:32imirkin: for BFI, it doesn't take a mask
19:32imirkin: it just takes 2 args packed into 1
19:33karolherbst: the thing is, we have to multiply by 8 in the end
19:33jekstrand: karolherbst: Are C-style bitfields a thing in OpenCL?
19:33airlied: I guess they are, but are they a thing in SPIR-V
19:33karolherbst: jekstrand: not sure actually
19:34karolherbst: might depend on the implementation :p
19:34airlied: nope they aren't apparently
19:34airlied: "Bit-field struct members are not supported in OpenCL C. "
19:34jenatali: I see some bitfield ops in SPIR-V, but they require the Shader capability, not Kernel
19:35karolherbst: oh well, lucky us
19:38jenatali: Anybody willing to explain me to the mess around GL compat contexts vs core contexts and why Mesa limits compat contexts to 3.1?
19:38jenatali: I keep reading things but I think I'm just getting myself more confused
19:39airlied: jenatali: mesa doesn't limit compat context anymore
19:39airlied: jenatali: the driver can pick to advertise higher ones now
19:39jenatali: I think the wgl winsys doesn't have that hooked up then
19:40airlied: you just have to et the compat glsl version in the driver
19:40karolherbst: jenatali: doesn't have to
19:40airlied: and run piglit to make sure you've covered at least some of the problem bases
19:40jenatali: Ahhh ok, I think I see what's missing
19:41airlied: jenatali: be careful, there is a lot of things that need work on driver side for compat context
19:41airlied: TBOs and legacy formats being the worst
19:42karolherbst: the solution is to ignore everything and only fix bugs :p
19:44jenatali: So if I understand it right, the problem with higher-versioned compat contexts is just interaction of legacy stuff with more modern features?
19:45karolherbst: like handling compute/tess shaders
19:45jenatali: Got it
19:45karolherbst: like user clip planes
19:46karolherbst: so pre core you only had to handle that for vertex shaders, but with compat you also have to do that in tess eval shaders (and potentially others)
19:46karolherbst: ahh yeah, geometry as well
19:46imirkin: and how ARB_dsa interacts with implicit texture ids :)
19:46jenatali: Yeah ok, I see
19:47imirkin: (hint: poorly)
19:47imirkin: a lot of those interactions weren't heavily considered, so they can just be "best effort"
19:48imirkin: until recently you couldn't enable GL_FEEDBACK with a modern pipeline
19:48karolherbst: I think all of ARB_compat is best effort :p
19:48imirkin: but airlied's been working heavily on that :)
19:48imirkin: so that now, finally, you can enable select buffers when you have tess, geometry shaders, ssbo's, and images, esp all at the same time.
19:49imirkin: heavily requested feature, to be sure
19:49karolherbst: not many applications actually care all that much :p
19:49imirkin: about select buffers? :)
19:49karolherbst: except it seems in so called "pro apps" the demand is higher for that
19:49karolherbst: genreally :p
19:51jenatali: Cool, makes sense. Sounds like something we'll probably want to look at eventually
19:53karolherbst: some benchmarks depend on it though...
19:56jenatali: Depend on what exactly? Just curious
19:58karolherbst: that you can create a 4.0 GL context with the legacy method
19:58karolherbst: aka a compat context
19:58karolherbst: and fail if it doesn't get 4.0 but only 3.1 or.. 2.1 or something :p
19:58karolherbst: apple eg totally abondoned it so they only advertise 2.1? maybe 3.0 by now? dunno
20:01jenatali: Got it, good to know
20:01airlied: karolherbst: you have to advertise 3.1
20:02airlied: since 3.2 introduced the pickingm mechanism
20:04karolherbst: apple didn't care :p
20:05kisak: filtering https://opengl.gpuinfo.org/ with Mac, looks like they didn't go past OpenGL 2.1 for the compatibility context
20:09jenatali: airlied: What do you mean you have to advertise 3.1? Looks like 3.0, 3.1 + GL_ARB_compatibility, or 3.2+ compat profile would all be valid options for the original context creation methods?
20:10airlied: jenatali: 3.2 is the first time there is a choice between core and compat
20:10airlied: you can't expose a compat version lower than 3.1
20:10jenatali: Oh I see what you're saying, sure
20:11jenatali: If you go below 3.1 it's not a compat version, it's just the GL version
20:11jekstrand: compat was a failed (thanks, Nvidia) attempt to depricate a pile of stuff when GL 3.1 came out.
21:30jekstrand: jenatali: Did you land the changes to nir_lower_io to promote local variables to scratch upstream?
21:30jekstrand: Hrm... Looks like not
21:30jenatali: jekstrand: No, not yet - I should go ahead and create that MR
21:30jekstrand: jenatali: That'd be cool. I think I may have need of them.
21:31jenatali: Sure, let me give that a shot
21:33nifker: Does mesa not contain the lima driver or why is it not mentioned in the mesamatrix.net?
21:34airlied: it's a gles2 only driver, not a huge amount to mention
21:34HdkR: mesamatrix only tracks features.txt which only tracks GL 3.0+ and ES 3.0+
21:34HdkR: (and vulkan)
21:39Kayden: that website's been a bit less useful now that we've mostly finished the features on the main drivers
21:39Kayden: if people wanted to work with the creator to track the status of things on the ARM drivers, that would be pretty neat
21:39bnieuwenhuizen: and for Vulkan we don't really update it ... I don't see 1.2 on there
21:40jekstrand: Yeah, it's kind-of pointless for Vulkan
21:40jekstrand: Just go to gpuinfo.org for that
21:40jekstrand: features.txt doesn't make much sense there.
21:40Kayden: it was helpful when we were checking off a lot of individual things over a long period
21:40bnieuwenhuizen: don't you have opengl.gpuinfo.org also?
21:40Kayden: but yeah, development's kind of shifted since then.
21:41Kayden: it was also tracking in progress work for us
21:43airlied: once I finish llvmpipe it'll be totally useless :-P
21:44HdkR: But what about Zink and newer drivers? :P
21:44zmike: I've been forgetting to update features.txt for my zink changes lately, so I'm not sure how accurate it is for that anyway
21:45Sachiel: update them all at the end so it looks like a massive amount of work done in one day
21:45airlied: Sachiel: gles 3.1/2 for llvmpipe will look like that
21:51nifker: Does zink even count as a "software" renderer?
22:00HdkR: It's at least software rather than hardware
22:03jenatali: jekstrand: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5889 should be what you need
22:04jekstrand: jenatali: Thanks! I'll try to get it reviewed/landed this week.
22:04jenatali: Sounds good
22:05jenatali: jekstrand: You don't need the additional addressing modes I added (64bit ptrs for 32bit offsets or index/offset pairs), right?
22:05jekstrand: 32bit pointers is fine
22:05jenatali: I was thinking that's what you were asking for at first and cherry-picked them, but it probably doesn't make sense to MR it until there's a driver that'd use them
22:08karolherbst: jenatali: cool stuff :)
22:09jenatali: While I'm at it let me see if there's other stuff I should extract...
22:11jenatali: karolherbst: Would you want the patches for supporting offsets in work IDs?
22:13karolherbst: jenatali: yeah
22:14karolherbst: I just need to figure out if I need the lowering though :D
22:14jenatali: Cool, I'll extract those and send them your way
22:14karolherbst: I will play around with them though
22:54jenatali: karolherbst: That was harder than expected, didn't realize a cap I relied on was in our downstream fork added by kusma. Anyway: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5891
22:55karolherbst: jenatali: right.. I add a comment being a TODO thing actually :D
22:56jenatali: Yeah it's all fully optional right now - if you don't do anything, all the lowering I added removes the concepts of offsets
22:56karolherbst: just need to change the gallium API I guess
22:57jenatali: Otherwise the offsets make it to the driver backend and you can map them to whatever you want
22:57jenatali: We're mapping them to UBO loads for the D3D12 backend
22:57karolherbst: but yeah.. I think it should be explicit then..
22:57karolherbst: like .needs_offset_lowering
22:57jenatali: Hm, I did the opposite, just to avoid touching all drivers that might want to support clover
22:57karolherbst: better idea
22:58karolherbst: yeah, I have an idea
22:58jenatali: has_cs_work_group_offsets, has_cs_global_work_offsets
22:58karolherbst: nir_intrinsic_load_global_invocation_id_with_offset == nir_intrinsic_load_global_invocation_id except !has_cs_global_work_offsets or so?
22:58karolherbst: anyway.. first I have to figure out if that's actually working
22:58jenatali: Yep, that's what the lowering does
22:58karolherbst: okay, cool
22:59karolherbst: sounds sane enough then
22:59jenatali: And the offset intrinsic gets lowered to (0, 0, 0) in that case too
22:59karolherbst: and then it just gets dced
22:59karolherbst: okay, gotcha
23:00jenatali: Btw, I don't have the ability to add labels/milestones/assignees. Not sure if that's expected
23:00karolherbst: only developers can :)
23:01jenatali: Ah, got it
23:01karolherbst: but yeah.. would be nice if at least the creator of issues/MRs could do it as well?
23:03jenatali: Yeah that's what I would've expected
23:08jenatali: jekstrand: You had said you wanted the 64bit phi lowering too, right?
23:52karolherbst:wondering if -fno-exceptions is something we want for mesa