00:14mattst88: airlied: I bet idr has one :)
00:15imirkin: i'd put money on vsyrjala
00:17airlied: I think I have one in the office, but I might have junked it
00:21airlied: man 13 years since I added tex rect support to i815 :-P
00:22airlied: 15 years since I wrote the patch
00:25imirkin: it's a little scary how time flies
00:26malice: imirkin: A LITTLE?
00:27malice: It is VERY scary
01:14imirkin: malice: i didn't want to start a panic :)
01:16zf: the best thing that you can do, is take whatever comes to you
07:13Venemo: jekstrand: can I ask you to review MR 4202 for us, please? it yields a big improvement for TCS
07:14Venemo: jekstrand: I think it will also help TCS in your drivers as well
07:31Lightsword: anyone know what might be causing an undefined reference to `vgPlain_tl_pre_clo_init' build error when trying to link libgbm? see here http://autobuild.buildroot.net/results/bc0/bc0c32a6daffc1213caf2ad7ebcf651b2305edcf/build-end.log for log
07:33mripard: Lyude: shouldn't we do it the other way around?
07:33mripard: ie, merge the fix in drm-misc-fixes, and resolve the conflict in next when it happens?
07:59pq: daniels, yeah, that's a technical detail of what happens with them. But what's the use case?
08:12linkmauve: Pentium 4 era motherboard says “Supports Integrated Intel® Extreme Graphics 2 and DirectX 8.0”, which Intel GPU is that?
08:13linkmauve: 865G it says about the northbridge.
10:56vliaskov: hi itoral, are there any special instructions for building piglit on rpi/aarch64? I am getting a python3 crash early during the build https://pastebin.com/wm1Dex6D (whereas piglit builds fine e.g. on x86_64)
10:58itoral: vliaskov: I don't think so, but maybe chema[m] knows better.
10:58itoral: (I have not built piglit on that target for a while)
10:59vliaskov: ok, thank you
11:07txenoo: Hi vliaskov , i compile it on raspbian and there is nothing special, maybe some dependency is not installed.
11:13txenoo: My recipe to build piglit from scratch is just:
11:13txenoo: cd piglit
11:13txenoo: git clean -xfdq
11:13txenoo: cmake -DCMAKE_BUILD_TYPE=Release . -G Ninja
11:13txenoo: cmake --build .
11:43bbrezillon: karolherbst: I'm working on atomic ops support for CL-on-D3D12 and DXIL atomic instructions take a semantics argument, meaning that we could group the mem_barrier(before_semantics)+atomic_X()+mem_barrier(after_semantics) into a single atomic_X_with_semantics(semantics) instruction
11:44bbrezillon: the question is, should we have spirv_to_nir() issue those atomic_X_with_semantics() instructions or should we add a DXIL-specific optimization pass
11:45karolherbst: bbrezillon: dunno.. btw, I have some atomic patches
11:45karolherbst: bbrezillon: https://gitlab.freedesktop.org/karolherbst/mesa/-/commit/da085a9ab5a943c7a6ed997866d26d6796b54217
11:45karolherbst: but I guess you already handle that in DXIL in some way (or drivers do)
11:46karolherbst: no idea about barriers though... it kind of feels counterintuative to merge the barrier with the atomic op
11:46karolherbst: as you could share a barrier with multiple ops as long as you know that this works out
11:47bbrezillon: not sure, I'll have a look
11:48bbrezillon: well, SPIR-V has it in a single instruction too
11:48karolherbst: yeah.. I guess DXIL is more high level than nir is
11:48karolherbst: but mhh
11:49karolherbst: I have no real opinion on that though. I just see that one could optimize here a little
11:50karolherbst: bbrezillon: well.. what about this: if all your atomics have an implicit barrier, you could just skip emiting barriers for atomics, no?
11:51karolherbst: you could add a spirv_to_nir option for that
11:51bbrezillon: karolherbst: it's not implicit
11:51bbrezillon: I have to specify the semantics I want to use
11:51karolherbst: mhh, true
11:51bbrezillon: and I still need to support explicit barriers
11:51bbrezillon: then the issue is about finding which ones are attached to atomic ops
11:51bbrezillon: and which ones are really necessary
11:52bbrezillon: BTW, I noticed that the scope attached to AtomicOp operating on local memory was Device
11:52karolherbst: bbrezillon: the bigger issue I see is that we will end up with lots of atomic ops.. we already have the deref vs !deref ones
11:52bbrezillon: I'd expect it to be WorkGroup
11:53bbrezillon: in the same vain (but not entirely related), I added a scoped_memory_control barrier intrinsic
11:54bbrezillon: that's because DXIL can't do control barriers that have no memory barriers attached to them
11:56karolherbst: bbrezillon: in regards to the semantic ones, I think it would probably make sense to add a semantics field to the deref variants and in lower_io decide what gets emited.. but overall that sounds like a bigger rework and I don't know what implications all of that would have
11:56karolherbst: especially as some drivers consume the derefs
11:56karolherbst: jekstrand probably has some strong opinions on that
11:57bbrezillon: karolherbst: I could definitely add a optimization pass to merge the mem_barrier(acq)+atomic_X()+mem_barrier(rel), but that implies having the right scope for the mem_barrier, otherwise I'll have a hard time figure out whether those can be merged or not
11:57karolherbst: I don't think going this route is working out that nicely
11:57bbrezillon: me neither :)
11:57karolherbst: splitting in with a nir pass is probably the better approach
11:57karolherbst: just needs fixing up some passes and maybe even drivers
11:58karolherbst: bbrezillon: are you consuming the derefs or lowered instructions?
11:58karolherbst: I'd assume deref
11:58karolherbst: no idea about dxil :)
11:58bbrezillon: for shared and global mem we consume the lowered instructions
11:58karolherbst: I see some work in front of you :p
11:59karolherbst: anyway, let's discuss this with jekstrand, maybe we will come up with a better plan then
13:11bbrezillon: karolherbst: another question related to atomics on global memory. Shouldn't they have the CrossWorkgroupMemory semantics flag set?
13:14pendingchaos: bbrezillon: would that optimization pass be correct? barriers apply to all memory operations, not just the atomic
13:14pendingchaos: IIRC bnieuwen1uizen mentioned that RADV has a similar issue btw
13:14bbrezillon: pendingchaos: no, that's the problem
13:16pendingchaos: ok, I must have missed it while reading the messages
13:16bbrezillon: well, I didn't mention that part actually :)
14:04sravn: linusw: What about panel-complicated or panel-everything or panel-... :-)
14:05linusw: sravn: haha :D
14:05sravn: linusw: Well the panels are simple, they just require more and more complex SW to handle all situations
14:06danvet: j4ni, on "[PATCH 38/59] drm/i915: Use devm_drm_dev_alloc" ack for merging through drm-misc or want to backmerge and all that?
14:06linusw: sravn: hm yeah, but given how many panels are actually complex just disguised as simple I'm suspicious about a whole lot of them.
14:06danvet: I don't mind since it's a huge pile of follow-up driver patches anyway
14:07linusw: sravn: I bet a ton of them actually have things like custom DSI commands to set gamma correction and what not :/
14:31jekstrand: bbrezillon: I think I'd like to eventually move NIR to having semantics on the individual memory ops.
14:32jekstrand: bbrezillon: When we first implemented the Vulkan memory model, barriers were what we had plumbed through everywhere and so that's what we did.
14:32jekstrand: On Intel, barriers are all we have so we really do need that. However, I think AMD and Nvidia both have some sort of per-op semantics information.
14:35bbrezillon: jekstrand: ok, I can try to work on that. I guess we'll need a lowering pass to generate those barriers for intel (and all drivers needed that do not handle semantics on memory ops)
14:53jekstrand: bbrezillon: Yup. We'll also have to very carefully think about what all the per-op stuff means for various optimization passes such as nir_opt_copy_prop_vars
15:31j4ni: danvet: ack, I don't care
15:32j4ni: (that came out more negative than intended; I don't mind either way is perhaps more accurate)
15:32Lyude: mripard: mhhh-yeah you are right, I already pushed something to drm-misc-next though :S (sorry-haven't had to do this before)
15:33danvet: j4ni, thx, I'll push it through misc then
15:37Lyude: mripard: how should we move forward?
15:43mripard: Lyude: I don't really know
15:44Lyude: mripard: i'm fine with waiting for it to hit master then just backporting it from there if that would be easier
15:44mripard: maybe the least messy would be to not push a fix for now, and just send the backport to stable directly when it's in linus' tree ?
15:44Lyude: mripard: seems we're in agreement :p, I wonder if I should add a section about this to the drm maintainer manual at some point
15:51mripard: Lyude: if you have some spare time, please go ahead :)
16:06tlwoerner: daniels: just a reminder, you wanted to talk about https://gitlab.freedesktop.org/freedesktop/freedesktop/issues/76 later this week, perhaps thursday or friday?
16:06gitbot: freedesktop.org issue 76 in freedesktop "Guiding new contributors" [Non-Technical, Opened]
16:11daniels: tlwoerner: yeah, either would be good for me :)
16:11daniels: but I did leave some thoughts on #xf-bod
17:06MrCooper: danvet: by "save&restore" you mean every DRM master should save the complete atomic KMS state when its VT becomes active, and restore it when it becomes inactive? I.e. basically what Xorg & friends did in the good old UMS days? ;)
17:14sravn: danvet: so we need to look at dw-mipi-dsi and dw-hdmi. Nice to know that there is enough to do when one start to poke a head into a new area.
17:16sravn: Hands are full of the chained bridge stuff, and I think we should try to fix it mostly before untangling other stuff.
17:17sravn: linusw: Yeah, many panles hides a simple. Good news is that we can migrate them out of panel-canpake^Wsimple anytime
17:28danvet: MrCooper, maybe other way round, you capture a full state once when you start
17:28danvet: then force-restore that
17:28danvet: when you switch back to being the active compositor
17:28danvet: otherwise too much being at the mercy of everyone else
17:28danvet: I still think pushing that into logind or similar would be best
17:29danvet: sravn, yeah I think we need to be pragmatic on this
17:29danvet: I only got into this because I read one of these patches
17:29danvet: and then noticed we have an entire pile that further the same old pattern of not-really using drm_bridge as a proper abstraction
17:29danvet: and somewhere we need to stop this
17:30danvet: otherwise we'll end up with 10+ users, and then it's going to be major surgery
17:30danvet: plus I do think all the fundamental issues (like device links not working on reload for EPROBE_DEFER and stuff like that) is fixed now
17:49pendingchaos: jekstrand: can you take a look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4757 ?
17:53jekstrand: pendingchaos: commented
18:27sravn: vsyrjala: would be good to get the reviewed patches applied soonish, so we do not gain new conflicts as there is never a week without a new panel
18:28sravn: vsyrjala: And no, I still do not feel I am competent to review the last patch - sorry.
18:30vsyrjala: yeah, just need to get it past the ci
18:38sravn: vsyrjala: sounds great
18:49krh: jekstrand: why is there a mode field on both nir_deref_instr and nir_variable, and what happens when they don't agree?
18:50krh: jekstrand: for example, print_deref_instr prints instr->mode but lower_io uses var->data.mode
18:50jekstrand: krh: nir_validate requires them to agree exactly
18:51jekstrand: krh: The mode exists for when you can't get to the variable
18:51jekstrand: Such as for Vulkan variable pointers
18:51krh: jekstrand: so lower_io_to_temporaries is broken then? It modifies var->data.mode but doesn't fixup the derefs... oh or is that what nir_fixup_derefs do?
18:52jekstrand: krh: That's what nir_fixup_derefs does. :)
18:53krh: there's function for everything
18:57krh: much better
18:58krh: jekstrand: one more question: is nir_copy_var suspposed to handle struct types?
19:00krh: it looks like nir_lower_var_copies just lowers it to load_deref and store_def pair on the top level var, which doesn't look right
19:02jekstrand: krh: Yes, it is
19:03jekstrand: krh: nir_split_var_copies is supposed to be run first
19:03jekstrand: krh: There'a a pass for everything. :)
19:05krh: I never doubted that - the tricky part is to figure which one it is :)
19:05krh: jekstrand: thanks!
19:06jekstrand: Yeah, bootstrapping a new NIR compiler is non-trivial
19:35karolherbst: jekstrand: on nv we have explicit barrier instructions
19:35karolherbst: nothing on the load/store/atom instructions afaik
19:36karolherbst: we can set caching modes on the load/stores
19:36karolherbst: but barriers are explicit
19:37jekstrand: Yeah, that makes sense
19:38karolherbst: we even used to have explicit texture barriers... but luckily nvidia got rid of them :)
19:38imirkin: still there
19:38imirkin: just part of the ISA-builtin-barriers now
19:38imirkin: instead of explicit ops
19:38karolherbst: imirkin: right... but I meant the normal ones
19:39karolherbst: like "wait on this tex to finish"
19:39imirkin: the old texbar's had a depth
19:39karolherbst: you mean the sched barriers
19:39karolherbst: ahh yeah.. sure
19:39imirkin: so you could say "wait until there no more than 2 texture ops outstanding"
19:39karolherbst: yeah.. but that we can't do anymore... except with being super hacky on those sched barriers
19:40karolherbst: or is there still a way to do this natively
19:40karolherbst:wondering what happens if you assign the same barrier to multiple instructions
19:51imirkin: karolherbst: "assign"?
19:51imirkin: you can tell an instruction to signal a barrier
19:51imirkin: or wait for one
19:52imirkin: if multiple instructions signal the same barrier, then ... multiple instructions signal the same barrier :)
19:53karolherbst: I assume bad things will happen
19:54imirkin: i forget how the reset happens exactly
19:54imirkin: or if it's a semaphore type thing
20:39austriancoder: eric_engestrom: at what time will you branch tomorrow?
20:40eric_engestrom: austriancoder: not sure, for one it might be a bit delayed depending on the MRs that are holding it (I actually just sent all of them a reminder a couple of minutes ago)
20:41eric_engestrom: I'll look at the status of all of them and start doing things at around 18:00 UTC I think, but we'll see on what exact commit the branch is cut
20:42austriancoder: eric_engestrom: okay... I try to land something before :)
20:43eric_engestrom: austriancoder: add your MR to the 20.1-branchpoint milestone so that I can easily see that you want your MR to be part of the 20.1 branch ;)
20:44austriancoder: eric_engestrom: will do
22:54anholt: folks that use RA: may want to look at https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4537 for a startup perf win
23:28Kayden: anholt: very nice.