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