00:47 robclark: bnieuwenhuizen: also modetest in libdrm/tests should dump out all the kms properties (and I believe it should parse out the formats.. if not that should be added)
00:58 krh: bnieuwenhuizen: and /sys/kernel/debug/dri/1/state
00:58 krh: or maybe 0
00:58 krh: doesn't list everything supported, but show current state
01:06 imirkin_: robclark: it does show supported formats.
01:07 imirkin_: (their fourcc codes, that is)
06:58 tomeu: MrCooper: maybe we should disable lima jobs for now while the skips and fails lists get updated: https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2935/diffs?commit_id=7b397a59ca3b7fa2629a5eebdf0a0b41bf0a6833
06:58 gitbot: Mesa issue (Merge request) 2935 in mesa "gitlab-ci: Automated testing with OpenGL traces" [Ci, Opened]
07:01 tomeu: if you give me a r-b for it, I will be able to merge that MR
07:01 tomeu: (or anybody else)
07:02 anarsoul: tomeu: rellla has his MR pending
07:03 anarsoul: but sure, r-b for this commit if it blocks you
07:05 tomeu: thanks!
07:48 elhoir: hello folks
07:48 elhoir: just a question... does mesa 20.0 bring OpenG support for amdgpu ?
07:49 elhoir: i have 19.3.3 with an AMD RX 470 and only OpenGL 4.5 is available
07:49 elhoir: just a question... does mesa 20.0 bring OpenGL 4.6 support for amdgpu ?
07:49 elhoir: (sorry)
07:50 HdkR: elhoir: https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Defaults-To-NIR For more information, but yes
07:51 elhoir: HdkR, thanks but this article talks abot radeonsi, not amdgpu
07:52 elhoir: oh, well, "finally for RadeonSI / AMD HD 7000 series and newer"
07:52 elhoir: yeah, maybe amdgpu included
07:55 HdkR: amdgpu is the kernel space, radeonsi is the GL userspace
07:55 elhoir: ahhhhh i didnt know that!
07:55 HdkR: amdgpu-pro is whatever the proprietary thing is
07:56 elhoir: thank you!
07:59 HdkR: https://gitlab.freedesktop.org/mesa/mesa/commit/75ce078a0aff7fa0f4d6467bea787327da3a4b69 This is the commit that did it :P
08:00 elhoir:cant wait to update his mesa packages :D
08:09 HdkR: You have an application that relies on GL 4.6? :P
08:16 elhoir: games mostly
08:16 elhoir: :)
08:20 HdkR: There are games that actually rely on GL 4.6? :P
08:24 elhoir: well i have no idea but i guess it will enhance performance
08:24 HdkR: eeeeh
08:24 HdkR: maybe
08:25 HdkR: :P
08:25 HdkR: Pessimistic until proven otherwise
08:26 HdkR: I guess larabel can confirm that with benches
08:26 elhoir: :)
08:37 hakzsam: oh great, CI traces support got merged!
08:37 hakzsam: time to rebase my Fossilize CI work :P
08:38 MrCooper: tomeu: doesn't seem necessary, just keep adding flaky tests as they pop up, and remember to mark such changes to be backported to stable branches as well
08:38 mkoncek: is it valid behaviour for unsuccessful glCompilerShader to call the the opengl debug callback, but not having set the shader status to unsuccessful and not having set its info log?
08:38 tomeu: MrCooper: well, the lima guys are still discussing how to best do that
08:39 tomeu: this is just so my unrelated stuff can get in
08:39 tomeu: because of state leaks, skipping tests can make other tests to pass or fail, so one can end up skipping most tests, or spend a lot of time finding the best combination of skipped tests
08:40 MrCooper: the question is more about how to get tests back off the skip list, adding them should be straightforward? :)
08:40 MrCooper: ah
08:49 pq: danvet, pinchartl, re: Bayer packing differences with linear formats; maybe by definition there are *no* linear formats? I.e. no mod-less format.
09:03 danvet: pq, it's not just the packing that's difference, but what you get
09:03 danvet: somewhat like yuv422 vs yuv420
09:04 danvet: but it's also full of hw specific packing and layout and everything, so dunno
09:06 pq: I never learnt what the numbers in yuv420 etc. actually mean... but sure. I'm just saying that if you have trouble defining what the format code without a modifier means, then just say it's invalid.
09:07 pq: or outlaw LINEAR mod for them
09:55 HdkR: robclark: turnip sets maxTexelBufferElements to 128 *1024 *1024 while the proprietary stack only sets it to uint16_t max. Is this the qcom blob being a derp or turnip being good? :P
11:18 MrCooper: there's no atomic driver which supports a HW cursor but doesn't expose a cursor plane, right?
11:26 pq: and would that even be possible at all, given what DRM core does?
11:48 MrCooper: anholt_ robclark: mesa-cheza GitLab runner seems to occasionally fail like https://gitlab.freedesktop.org/mareko/mesa/-/jobs/1679687
12:03 pq: MrCooper, reading drm_mode_cursor_common() it seems that being an atomic driver does not stop you from implementing and getting called on the legacy crtc set_cursor funcs.
12:04 pq: err, cursor_set funcs
12:59 pq: MrCooper, EVDI seems to do exactly that FWIW: not implement a cursor plane, but implement cursor_set2 instead to be "faster", as it never implemented that async funcs that would allow updating cursor position more often than the normal refreshes.
13:19 MrCooper: pq: ugh... I tend to agree with what you said on #gnome-shell, such a driver deserves what it gets :)
14:56 tomeu: MrCooper: anholt_: maybe we should have a separate job for build-testing on arm64, as otherwise the mesa built in meson-arm64 requires llvm which makes the ramdisk images much much bigger
14:59 MrCooper: makes sense, assuming the ARM drivers don't hit any Gallium draw module paths which benefit from LLVM
15:02 imirkin_: all gallium drivers use draw for handling feedback/select render modes
15:02 imirkin_: not *exactly* a highly common case...
15:15 tomeu: we used to run just fin without llvm, until amdvk was added to the arm64 build
15:41 robclark: MrCooper: I hit something like that.. and then I rebased and pushed again and it was fine.. *shurg*
15:42 shadeslayer: tomeu: MrCooper : so perhaps something like so https://gitlab.freedesktop.org/shadeslayer/mesa/commit/e32e8edea1f3178b35e0d7f53215be2d8502797d
16:08 danvet: pinchartl, devres on kref sounds like a good idea
16:08 danvet: pinchartl, so I think for the design questions it's probably best we continue the discussion on the last patch first?
16:13 anholt_: MrCooper: yeah, that's started recently. I think it might be on the new runners, which have a newer gitlab-runner.
16:14 anholt_: trying to switch off of gitlab-runner on the devices asap because maintenance is a nightmare.
16:17 pinchartl: danvet: sure. and just to be clear, I think the series can be merged, we can refactor on top
16:59 mripard_: danvet: was anything wrong with the previous drm-misc-next PR? it doesn't look like you merged it?
16:59 danvet: mripard_, oh generally I let airlied to the merge
16:59 danvet: and I think generally he waits for some other pull to show up
17:00 danvet: so either agd5f_ or vivijim for -amd or -intel
17:00 danvet: mripard_, do you need some backmerge or something?
17:00 mripard_: danvet: no no, I was about to send the next one and noticed the first one didn't get in
17:00 mripard_: that's unusual, so I was intrigued, that's all :)
17:04 danvet: yeah maybe time to nag airlied :-)
17:04 andrzej_p: danvet: thanks for your thoughts on my AFBC series. I will have a look tomorrow.
17:05 danvet: andrzej_p, yeah sorry for the totaly confusion
17:05 danvet: but I scrolled through the patch series and looked at the diffstat
17:05 danvet: and just didn't feel like this is really improving the code
17:05 danvet: ofc I don't know whether my proposed interface will improve drivers, but should at least be fairly simple interface
17:06 danvet: and if that doesn't work I guess time to give up and just copypaste the code :-/
17:08 danvet: andrzej_p, https://paste.debian.net/1131274/ as a very rough sketch, what I have in mind
17:08 danvet: ofc needs a bunch more adjustments to compile :-)
18:47 ajax: can we get lsof to print something more interesting than /i915 for drm objects?
18:49 anholt_: we really need to build some shared infrastructure for debug naming of gem bos.
18:49 imirkin_: that's a good parting thought...
18:53 ajax: anholt_: glObjectLabel perhaps
18:56 danvet: just stuff the type/size of gl obj in there is probably really good already
19:00 Kayden: bo->name in i965/iris is at least somewhat better
19:00 Kayden: but never communicated to the kernel...
19:13 ajax: for that matter, where does /i915 even come from
19:24 danvet: ajax, I have no idea
19:24 danvet: we allocate an anon inode for book-keeping of these mmaps
19:24 danvet: but that doesn't have a name
19:32 ajax: show_map_vma() suggests vma->vm_ops->name()
19:47 airlied: mripard_: I merged it locally yesterday, just hadn't pushed it out yet
19:52 danvet: ajax, not setting that, but I guess it's the /dev file name that's used
20:07 Venemo: jekstrand: in NIR, how do I get the proper driver location from an intrinsic instruction? I assume it should it be (base + component + offset), is that correct?
20:08 jekstrand: Yup
20:08 jekstrand: Not all of them have BASE
20:10 Venemo: what exactly does component mean here? if it's a constant that should be just added to the base, why is it a separate variable?
20:10 jekstrand: Ok, I should back up....
20:10 jekstrand: It depends on what type of thing you're looking at.
20:11 jekstrand: UBOs and SSBOs just have an offset from the start of the buffer
20:11 Venemo: I'm looking at load/store_(per_vertex)_input/output for TCS
20:11 jekstrand: push constants have base+offset and a range so that you know exactly what range is being accessed even for indirect access
20:11 jekstrand: inputs and outputs have base which is a location number (counted in vec4s)
20:11 jekstrand: component is a component offset within the vec4
20:12 Venemo: ah
20:14 Venemo: what do you mean by a vec4? is it just a 4-byte value?
20:14 jekstrand: No, shader inputs and outputs are typically referenced a vec4 at a time
20:14 jekstrand: so 16 bytes
20:14 jekstrand: technically, I think you can tell NIR to use units of bytes or something like that if you want but I don't think anyone does.
20:15 Venemo: I don't want to tell it anything, just wanna understand where the magic numbers come from
20:15 Venemo: so base and offset are in 16-byte units, and component is in 4-byte units?
20:15 jekstrand: yes
20:16 Venemo: so to get a real address out of it, it should be: (base + offset) * 16 + component * 4
20:17 jekstrand: yup
20:17 Venemo: ok I think I just understood why we assign driver_location = location * 4, and then multiply the whole thing by 4 at the end
20:19 Venemo: thx jekstrand
20:19 jekstrand: yw
20:19 Venemo: this has been bugging me to no end, for a few days now :)
20:19 jekstrand: :(
20:27 imirkin_: Venemo: another wrinkle in TCS outputs is that you can read *other invocations* outputs, but write your own. so the reads take an extra parameter for the invocation id, which can work itself way into the addressing too.
20:28 Venemo: jekstrand: so if we set driver_location to location * 4 before lowering io, does that mean that the base and component are in the same 4-byte units then? and the offset too, or does the offset still need an additional * 4?
20:28 jekstrand: likely, yes, but I don't know about the particular driver you're working on.
20:28 Venemo: imirkin_: yes, fortunately that wasn't hard to implement
20:29 Venemo: jekstrand: no problem, I trust your likely yes. I work on aco :)
20:30 Venemo: imirkin_: the hard part is that we have to separately deal with the outputs that might be read by other invocations
20:31 Venemo: which is fine
20:31 Venemo: just a lot of work
20:31 Venemo: and every time I feel that I'm done, it turns out that I still missed yet another detail
20:35 imirkin_: Venemo: yeah. at least you have a working implementation to copy from.
20:35 Venemo: yes, that helps tremendously
20:35 Venemo: I can't imagine how much time it took them to get it right for the first timr
20:36 Venemo: time*
20:36 imirkin_: well, presumably they worked with docs :)
20:36 imirkin_: which also help
20:37 Venemo: I work with docs, and a reference implementation, and still don't feel that it's easy
20:47 jljusten: I added some DBG messages to iris_blit.c, and now when gallium-nine is enabled, I'm seeing: src/mesa/main/texcompress_fxt1.c:1311: undefined reference to `_glapi_tls_Context'
20:48 jljusten: any ideas what I missed? there's no build error if gallium-nine is disabled
21:12 jljusten: hmm, the DBG uses _mesa_get_format_name, and that seems to cause the undefined reference
21:15 Venemo: do the tess factors count as per-patch outputs?
21:16 anholt_: ajax: I'm not concerned about that side of things, it's that we have no kernel infrastructure for tracking object names
21:16 pendingchaos: Venemo: yes
21:17 Venemo: ok, cool
21:26 HdkR: robclark: oop, nevermind my dumb question, apparently the blob's latest drivers also kick the texel element limit up significantly :)
21:28 robclark: HdkR: oh, whoops, I didn't see your question in the first place..
21:29 HdkR: No problem, it was rogue curiosity than something I really needed to know
21:30 HdkR: rather than*
22:31 Venemo: jekstrand: is there a function that would give me the correct offset src for any intrinsic instruction? so I wouldn't need a switch case? or should I hardcode them?
22:33 jekstrand: nir_get_io_offset_src
22:35 Venemo: awesome, thanks
23:31 jekstrand: How crazy would it be to add predication back to NIR?
23:31 jekstrand: In a constrained way, of course.
23:31 jekstrand: Predicated instructions would still have SSA defs, they would just be undefined if the predicate is false.
23:32 jekstrand: The reason why I ask is that I keep coming across cases where I want to predicate an instruction but I want to do the lowering in NIR because our back-end is a pain and we have 3 of them.
23:32 jekstrand: But doing full-on control-flow makes hash of the scheduler
23:32 HdkR: Watch out if you look up ideas about predicated SSA IR, someone has..patented? a method
23:33 jekstrand: I don't want to know
23:33 jekstrand: about any patents that is
23:33 jekstrand: cwabbott: ^^
23:33 HdkR: I was looking at the idea 1.5 years ago and someone pointed me to one then had to have a legal talking to about it :/
23:33 jekstrand: I'd rather be able to claim ignorance, thank you
23:34 bnieuwenhuizen: jekstrand: that sounds either very invasive or just like metadata ...
23:34 jekstrand: bnieuwenhuizen: It could be done as an after-the-fact instruction
23:35 jekstrand: nir_intrinsic_predicate(predicate, predicated_thing)
23:35 bnieuwenhuizen: isn't that pretty bmuch a bcsel(predicate, op, undef)?
23:35 jekstrand: Yeah, except I want the behavior that the predicated thing doesn't execute
23:35 jekstrand: For handling things like atomics and helper invocations
23:35 jekstrand: Or, in this case, an OOB texture instruction
23:36 jekstrand: for shader-generated bounds checking
23:36 bnieuwenhuizen: well, then you have to teach all other passes not to remove it?
23:36 jekstrand: Yeah....
23:37 jekstrand: That's why I don't like the idea of making it an instruction
23:37 bnieuwenhuizen: or put things in between, like a phi or something
23:37 jekstrand: But I want it to be very light-weight
23:37 jekstrand: We could do it as an intrinsic that's a bcsel with undef and it's up to the back-end to actually do a predicate
23:38 bnieuwenhuizen: jekstrand: do you only care about a few texture-linke instructions or significant amounts of different instructions?
23:38 jekstrand: It'd be pretty limited
23:38 jekstrand: Well, limited to external memory messages
23:39 jekstrand: Stuff that's has side effects or is expensive if you actually execute it
23:39 bnieuwenhuizen: cause then you might try adding a HW-specific NIR intrinsic and then lower in a nir pass?
23:39 jekstrand: I don't care for simple ALU stuff
23:39 bnieuwenhuizen: which could take predicate as input
23:40 jekstrand: Yeah, that could be made to work.
23:40 bnieuwenhuizen: I assume at least that the entire problem is a "near instruction selection" thing
23:40 bnieuwenhuizen: so if we add predicates to nir the question is how do we not confuse people in thinking they have to deal with it
23:40 jekstrand: I could also add a back-end optimization that is "if this thing is only used by a single bcsel, predicate it"
23:40 bnieuwenhuizen: jekstrand: stores might be messy though
23:41 jekstrand: Right, no SSA def
23:41 bnieuwenhuizen: with the bcsel thing