00:22 imirkin_: cmarcelo: does intel not support variable workgroup sizes? seems like https://cgit.freedesktop.org/mesa/mesa/commit/?id=ff5b74ef32ea0ccff265064017f8168a4b328a5a would be problematic in that case.
00:24 imirkin_: indeed, looks like ARB_compute_variable_group_size is unsupported on intel. nevermind.
00:27 cmarcelo: imirkin_: yep, it still doesn't. there's an open MR to implement it but got a bit stale...
00:28 imirkin_: yeah, that's fine. it'll have to consider that, i guess.
00:28 imirkin_: could probably do like if == 0, then return 1024 or whatever
00:30 cmarcelo: I added a note to the ARB_compute_variable_group_size MR to make sure we don't forget it :)
00:30 imirkin_: clever.
00:51 ngcortes: heads up, the public mesa ci results site will be down momentarily for an upgrade
00:54 Kayden: it's kind of crazy that the MR for that was posted 7 months ago
00:54 Kayden: and no activity in 4-5 months
01:00 anarsoul: out of curiosity, does anyone have a theory why Mali4x0 specifies a register to take gl_FragColor from 4 times in render state?
01:00 anarsoul: that's not 4 components
01:52 mareko: okias[m]: I'm not aware of any ARM users of radeonsi
02:06 MaxLeiter: I'm working on packaging mesa for a unix-like OS with swrast, and when others install mesa (I used DESTDIR to package) with the LFS glxgears patch, glxgears/glxinfo report: Error: couldn't get an RGB, Double-buffered visual
02:06 imirkin: try it with LIBGL_DEBUG=verbose
03:07 anholt_: anarsoul: it supports 4 render targets, and that lets you do gl_FragColor vs gl_FragData[]?
03:07 anholt_: (guessing)
03:34 anarsoul: anholt_: I need to change all them at once in order for shaders to work
03:34 anarsoul: if I leave out one of them then result is weird
03:36 anarsoul: also it supports only up to 3 render targets
06:44 tomeu: mareko: okias[m]: I heard of people using radeonsi on ampere workstations
08:08 danvet: j4ni, I think if you can coerce seanpaul into acking drm_WARN we're hopefully good enough
08:08 danvet: otherwise not seeing anyone with opinions about how drm driver debug output should happen
08:32 MrCooper: Venemo: please use Marge for merging MRs
08:32 Venemo: MrCooper: care to elaborate?
08:33 MrCooper: what's unclear?
08:35 Venemo: why do I need Marge?
08:37 Venemo: what's wrong with the "Merge when pipeline succeeds" button?
08:41 MrCooper: see e.g. https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3402#note_389654
08:41 gitbot: Mesa issue (Merge request) 3402 in mesa "panfrost: Fix naming conflict between bifrost & midgard compiler backends" [Android, Panfrost, Merged]
08:41 MrCooper: there were also mesa-dev list posts about it
08:41 Venemo: okay
08:42 Venemo: I assigned the next one to the marge bot
08:42 MrCooper: also, if you merge manually and it interferes with Marge, she gets upset ;)
08:42 MrCooper: thanks
08:54 mlankhorst_: danvet: hmm, time to open drm-misc-next-fixes I suppose?
08:56 airlied: mlankhorst_: yup I think it should be
09:00 mlankhorst_: pushing :)
09:00 mlankhorst_: drm-misc-next-fixes is now open!
09:21 j4ni: seanpaul: may I have your ack on http://patchwork.freedesktop.org/patch/msgid/20200115034455.17658-2-pankaj.laxminarayan.bharadiya@intel.com please?
09:23 j4ni: mlankhorst_: mripard: your acks would be appreciated as well on ^, can I merge via a topic branch so that I can start applying changes in i915 immediately?
09:29 mripard: j4ni: you can add mine
09:39 j4ni: mripard: thanks!
10:38 mlankhorst_: j4ni: irc ack enough?
10:42 dj-death: oh noes, gitlab times out
10:50 j4ni: mlankhorst_: sure, thanks a lot!
12:01 GreyXor: Hi, someone can help me to build mesa ?
12:01 GreyXor: i need to try an branch to debug my hardware
12:09 daniels: Venemo: whenever you rebase a tree, a CI job will be run. Marge takes each approved MR into a queue, rebasing them one-by-one and then pushing when their CI has succeeded. without Marge, you get a thundering herd: people rebase (CI runs), then can't merge because someone else's MR landed first, so they rebase again (another CI run), etc etc.
12:09 daniels: the resulting contention on CI means that everyone's pipelines take longer, meaning that they rebase more often, making the contention worse ...
12:09 Venemo: daniels: understood. yes, that makes good sense :)
12:10 daniels: a good counterpoint is 'so why do we have a big button at the top saying "merge"?'
12:10 daniels: to which my preferred answer is 'only allow Marge and no-one else to merge'
12:11 Venemo: can the button be changed to do the right thing?
12:24 daniels: possibly at some point in the future but not soon
12:24 Venemo: okay
18:15 imirkin_: is there an easy way to do the equivalent of "dmesg -w" when you have a version of dmesg that's too old?
18:15 imirkin_: like tailing /dev/kmsg or something?
18:16 ickle: cat /dev/kmsg
18:17 imirkin_: cat: /dev/kmsg: Invalid argument
18:21 ickle: my reading of devkmsg_read() says that is output buffer too small for message packet
18:21 ickle: assuming it got that far
18:22 imirkin_: sounds like "no", then, for easy ways
18:23 turol: cat /dev/kmsg works for me
18:23 turol: you might need to sysctl kernel.dmesg_restrict = 0
18:23 kisak:waves to pipeline 100000 as it goes by
18:23 imirkin_: turol: already 0
18:23 ickle: restrict should be EPERM
18:23 Kayden: but did pipeline 99999 do critical damage to the CI? :)
18:23 imirkin_: this is probably not _the_ most recent kernel
18:24 imirkin_: let's just say it matches the version of dmesg which doesn't have "-w" support :)
18:25 linkmauve: Speaking of kmsg, how could I increase its buffer size to see what was printed out at early boot?
18:25 imirkin_: there's a kernel cmdline thing
18:25 imirkin_: log_buf_size=100M
18:25 imirkin_: or osmething like that
18:25 linkmauve: Thanks. :)
18:26 imirkin_: log_buf_len=100M
18:26 imirkin_: i was close.
18:26 imirkin_: thanks to the NLP built into the kernel, it should be able to work things like that out :)
18:27 imirkin_: boo - only K/M/G suffixes supported. so if you want 1TB of your ram to go to the kernel log buffer, you'll have to type it out in G
18:27 dcbaker: PSA: Mesa 20.0 branchpoint is schedules for 2020/01/29, the release milestone is https://gitlab.freedesktop.org/mesa/mesa/-/milestones/9
18:28 Kayden: thanks for the heads up!
18:28 imirkin_: and more relevantly, apparently n has to be a power of 2, so 100M -> 128M
18:28 imirkin_: or whatever
19:22 mattst88: MR from someone that doesn't have commit access
19:23 mattst88: I review, add my tag, force push to his/her branch and assign to Marge-Bot
19:23 mattst88: what stops that person from pushing a bunch of crap to their branch after I've assigned to Marge and getting that committed without review?
19:24 airlied: nothing, but at that point they've already owned all your CI infrastructure :-P
19:24 mattst88: does Marge automatically unassign itself when the author pushes more stuff to that branch?
19:25 mattst88: (I'm looking at https://gitlab.freedesktop.org/mesa/mesa/merge_requests/3231 as a concrete example)
19:25 gitbot: Mesa issue (Merge request) 3231 in mesa "Do not require libdrm for DRI2 on hurd" [Meson, Opened]
19:27 anholt_: mattst88: a re-push unassigns from marge
19:27 mattst88: okay, cool
19:28 mattst88: it looks like that didn't happen in this case -- perhaps because only the commit message changed
19:30 anholt_: mattst88: my bet would be that marge is off testing other stuff and hasn't swept the MR list again
19:30 kisak: marge's attention might be elsewhere, could something like that be delayed until it's the current task in the queue?
19:30 anholt_: (it's very single threaded)
19:30 mattst88: ah, I see
19:53 Kayden: is there a way to see what marge is doing?
19:54 Kayden: because sometimes you assign it and nothing happens for 30+ minutes
19:54 Kayden: and so you're kind of left wondering ... is marge around and online? has she just not gotten to that request yet? or is it never going to happen?
19:55 anholt_: Kayden: nope, it doesn't put up any web interface or anything, just the kube logs
19:55 Kayden: the other day I assumed marge was still broken due to the gitlab updates, and unassigned marge, rebased, and merge when pipeline succeeds...then marge came back and cancelled it all, and then said "somebody did something, nooo" and bailed
19:56 Kayden: so reassign to marge, and finally happened - would've happened faster if I just left it, but... :)
19:56 anholt_: well, I guess you could watch https://gitlab.freedesktop.org/marge-bot
19:56 Kayden: ah! true
19:56 Kayden: yeah, that at least answers the "has marge been around today" question :)
19:59 kisak: !eightball are we going to see an overloaded CI workload next wednesday
20:02 kisak: mattst88: I wonder if some of the merge requests you queued up would have landed by now if you had cancelled the CI jobs on the pull requests that were going to get fast forwarded by marge and tested then. there's a throwaway iteration in there from adjusting the commit messages
20:03 mattst88: kisak: your guess is probably better than mine
20:04 mattst88: kisak: maybe I should just make sure that the MRs I'm assigning to Marge rebase cleanly and /don't/ rebase/push myself?
20:04 mattst88: or does CI still trigger if just the commit message is updated? that would be... stupid.
20:05 kisak: it looked like CI was doing a fresh batch on commit message change
20:05 mattst88: sigh :(
20:06 kisak: in the simple case, Marge picks up the assignment, rebases, and the throwaway step gets auto-cancelled
20:06 Kayden: yeah, it would be nice if it didn't re-trigger when the only change is the commit message
20:06 kisak: but when 2 are assigned to marge at the same time, the second queued pull request pulls CI time until marge gets to it and rebases
20:07 mattst88: https://gitlab.freedesktop.org/mesa/mesa/merge_requests?scope=all&utf8=%E2%9C%93&state=opened&assignee_username=marge-bot
20:07 Kayden: (queue the mention that not adding R-b type tags in the commit messages would also fix that)
20:07 mattst88: yeah, I suspect I totally clogged up the pipes by reviewing/rebasing/pushing a bunch of outstanding MRs and assigning to marge
20:07 mattst88: true
20:09 Kayden: glad to see that happen regardless :)
20:09 mattst88: alternatively... people could spread the load a bit more (both in review/merging others commits and CI) :)
20:09 mattst88: poor Samuel with his four Hurd patches, all clogging CI
20:10 mattst88: really should have just been one MR I suppose
20:27 capOM: Hi, is there an equivalent to https://mesamatrix.net/ but for EGL ? I would like to know how mature is EGL in Mesa, thx
20:29 kisak: maybe it would make sense to call for everything that's going into mesa 20.0 to land 48 hours early, so that the CI work gets spread out and just-in-time projects can land without hassle
20:30 kisak: (as a friendly reminder)
20:31 imirkin_: capOM: EGL is pretty much identical across (non-ancient) drivers
20:31 imirkin_: hrmph, i965 is missing EGL 1.5. surprising.
20:41 capOM: imirkin_: Thx, would be great to reflect that in a matrix
20:43 imirkin_: well, mesamatrix.net is just a prettifier for features.txt
20:44 imirkin_: i tried my own attempt at this based on actual data, but getting people to submit data is harder than pulling their teeth over the internet.
20:44 imirkin_: (https://people.freedesktop.org/~imirkin/glxinfo/)
20:45 degasus: imirkin_: I'm really sad that this page got outdated that hard. It was the best source for this kind of information
20:46 imirkin_: i gave up maintaining it
20:46 imirkin_: anyone (in the mesa group) can push to it though
20:46 anarsoul: ivb is at 4.5
20:46 anarsoul: for quite a while
20:46 degasus: understandable. I just wanted to say "thank you"
20:46 anarsoul: hm
20:47 anarsoul: looks like I'm wrong
20:47 imirkin_: yw :)
20:47 anarsoul: it's indeed at 4.2
20:47 imirkin_: anarsoul: as you can see at the top, this is for mesa 17.2
20:47 imirkin_: i have data as recently as 18.0
20:47 imirkin_: but only for nouveau
20:47 imirkin_: (coincidence, i'm sure)
20:47 anarsoul: imirkin_: ivb is ~8yo
20:48 anarsoul: if not older
20:48 imirkin_: ok, but mesa didn't always have pre-release hw support for everything
20:48 imirkin_: in fact, there was a time when GL 4 wasn't fully supported at the mesa level, believe it or not
20:49 imirkin_: https://people.freedesktop.org/~imirkin/glxinfo/#v=Mesa%2010.4.0
20:49 imirkin_: for example.
20:49 imirkin_:started hacking on mesa just before GL 3.2 support was added
20:50 imirkin_: i should probably do a "final" round of data collection
20:50 imirkin_: for 20.0 or something
20:52 anarsoul: ha, looks like my first commit in mesa was in 2011, but it was pretty minor and I had 8 years break afterwards
21:05 robclark: imirkin_: I suppose w/ CI running stuff on real hw.. it would be nearly possible to update glxinfo automagically.. supposedly there is a way to setup scheduled CI runs (like, run glxinfo every thing)..
21:06 imirkin_: happy to assist in explaining how my thing works to the next person :)
21:07 anholt_: robclark: with drm-shim, you don't even need hw
21:07 imirkin_: it's a lot of fixed, data-driven js ... just need to massage some of the inputs
21:10 robclark: oh, good point on drm-shim.. I guess that would need some periodic maintenance (ie. like when there is a feature that is only exposed depending on kernel version)
21:11 anholt_: yeah, but it's usually of the form "case DRIVER_GETPARAM_HAS_NEW_THING: return 1"
21:12 robclark: right
21:24 Kayden: i965 doesn't have EGL 1.5 because of OpenCL interop, IIRC.
21:24 MaxLeiter: LIBGL_DEBUG didnt work, do I need to compile with a flag imirkin?
21:24 MaxLeiter: Nothing new printed
21:24 imirkin_: MaxLeiter: no, that should just work
21:24 imirkin_: if you're using libGL, that is
21:43 MaxLeiter: imirkin_ I am
21:43 MaxLeiter: hm
21:44 imirkin_: MaxLeiter: LIBGL_DEBUG=verbose glxinfo > /dev/null
21:44 imirkin_: what does that print?
22:29 MaxLeiter: iPhone:~ root# DISPLAY=:1 LIBGL_DEBUG=verbose glxinfo > /dev/null
22:29 MaxLeiter: Error: couldn't find RGB GLX visual or fbconfig
22:29 MaxLeiter: imirkin_
22:31 imirkin_: that's it?
22:31 MaxLeiter: oh hm imirkin_
22:31 MaxLeiter: it seems DESTDIR didnt install swrast.so
22:31 imirkin_: oops
22:32 MaxLeiter: any clue if theres something special I neeed to do for packaging?
22:32 imirkin_: probably. look at how others do it? no idea how this stuff all works with meson.
22:33 imirkin_: iirc the point of DESTDIR is that you're the one that has to move it there.
22:33 imirkin_: but i'm no authority on this stuff.
22:34 MaxLeiter: nah DESTDIR is just where to install the files, and now I need to figure out how to see how others did it
22:34 MaxLeiter: thanks
22:34 MaxLeiter: oh huh, seems it didnt build swrast last time
22:35 imirkin_: anyways, sounds like glxinfo isn't the issue ;)
23:15 endrift: Are integer textures just slow in i965?
23:16 endrift: I'm seeing a lot of performance issues when I use them on Intel
23:16 endrift: (RGBA8I specifically)
23:17 imirkin_: any particular flavor of i965?
23:18 imirkin_: like ivb with texture borders?
23:18 imirkin_: (or does i965 even do those fallbacks?)
23:18 endrift: gen9.5, no borders
23:18 endrift: I'm on coffeelake
23:18 endrift: I think that's 9.5
23:20 endrift: also getting a few warnings for Integer fast clear not enabled for (MESA_FORMAT_RGBA_SINT8)
23:20 endrift: Which I assume is a driver limitation
23:21 imirkin_: hardware, i'd assume
23:22 endrift: Is there an intel-specific channel that would know better?
23:23 endrift: (also I guess by driver limitation I meant "either unimplemented or can't be implemented due to hardware")
23:24 imirkin_: #intel-3d
23:24 imirkin_: although tons of overlap between the people
23:26 endrift: I figured
23:26 endrift: thanks
23:27 endrift: hm, gles3 doesn't seem to have any 16-bit integer textures
23:27 imirkin_: EXT_texture_rg probably
23:27 imirkin_: erm
23:27 imirkin_: nevermind.
23:28 endrift: oh, rg
23:28 endrift: those are listed here but I don't know if they're core in gles3
23:28 imirkin_: they're not core
23:28 imirkin_: hm. they MIGTH be core.
23:28 imirkin_: ugh, sorry. i used to remember this stuff. but i clearly don't anymore
23:29 imirkin_: GLES3 includes rg.
23:29 HdkR: RG8 is core yes
23:29 imirkin_: there's also GL_EXT_texture_norm16 for R16 & co
23:29 imirkin_: but i thought integer textures should be there in GLES3 directly.
23:30 endrift: I'll see if rg8 is any faster
23:30 endrift: I'm only using a few bits of each channel
23:30 endrift: 2, 3, 2, 1 respectively I think
23:30 imirkin_: just do R8 :)
23:31 endrift: oh wait I'm wrong
23:32 endrift: 2, 4, 5, 1
23:33 imirkin_: there really should be a R16UI on GLES3
23:33 imirkin_: are you *sure* it's not?
23:33 imirkin_: i see it in the gles3 spec
23:34 imirkin_: (numbered) page 129
23:34 endrift: by 16-bit I meant 16bpp not 16bpc
23:34 imirkin_: oh
23:34 imirkin_: RGBA4 :p
23:34 endrift: not integer
23:34 endrift: honestly I'd love 565
23:34 imirkin_: well, R16UI and RG8UI are also both supported.
23:35 endrift: I'll try those
23:35 endrift: hopefully they'll be faster
23:35 endrift: I just don't want to hit slow paths even if I am processing less data
23:35 imirkin_: yeah =/
23:36 endrift: I suspect R16UI is like 4 slow paths in one--16bpc, integer, unsigned, one channel
23:36 endrift: *one color channel
23:36 endrift: this also needs to work on TX1 with Nouveau :x
23:38 imirkin_: nouveau is fairly standards compliant ... passes the GL45 CTS
23:38 imirkin_: (just not with all the tests run in one go... sigh...)
23:39 imirkin_: if you find bugs, please report them
23:40 endrift: of course