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