00:00 Lyude: oh hold on, I see where I'm getting confused. intel_connectors have an atomic_check hook but intel_encoders just have a compute_config hook
00:00 danvet: compute_config is essentially the i915 version of encoder->atomic_check
00:31 imirkin_: mareko: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/nouveau/nvc0/nvc0_state.c#n445
00:31 imirkin_: do you agree with the second loop which wipes out old samplers, or not?
00:48 mareko: imirkin_: it's wrong
00:49 mareko: imirkin_: the function should only update slots as specified by the start/count parameters
00:50 mareko: so, the nvc0->num_samplers variable is BS
00:51 imirkin_: ok. that's not how it used to work. sigh.
00:51 mareko: set_sampler_views is wrong too
00:51 imirkin_: you sure are redefining a lot of gallium api's lately :(
00:52 mareko: lately? :)
00:52 mareko: it's been a while
00:52 imirkin_: well, people are noticing now.
00:52 bnieuwenhuizen: because of the 18.0 rc's?
00:53 imirkin_: wonder how many other drivers are subtly broken...
00:54 imirkin_: looks like freedreno's ok
00:55 mareko: bind_sampler_states has had start_slot since 755d788fe24732127af0997f26e2fb61e5aa6173 Brian Paul <brianp@vmware.com>, Thu Oct 3 14:05:26 2013
00:55 mareko: so not "lately"
00:56 mareko: it was right for me to make the assumption about drivers that I made last year
00:56 imirkin_: looks like swr is also broken by this
00:56 imirkin_: https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/swr/swr_state.cpp#n287
00:57 imirkin_: mareko: just like it'd be right for me to revert that series until it's reworked to not break things...
00:57 imirkin_: but i probably won't do that
00:59 mareko: I can't agree with you, and if swr was broken, I'm sure people would notice, assuming swr devs run piglit
01:00 imirkin_: ok.
01:03 mareko: stuff gets accidentally broken all the time, so what can we do correct that? I guess we could just revert and keep the mesa history at year 2010 to make sure nothing is broken and nothing will ever break
01:03 imirkin_: i don't mind stuff getting broken - like you say, it happens, and quite a bit
01:05 imirkin_: but it seems like there's not a lot of checking going on when changing APIs around with what other drivers do
01:05 imirkin_: esp for something as undocumented and untested as messing about with start and nr with set_sampler_states & co
01:05 imirkin_: and then the attitude becomes "well, that driver is wrong", not "my interpretation of the api was wrong"
01:26 airlied: is the mesa-dev list down?
01:28 robclark: hmm, MAINTAINERS+scripts/get_maintainer.pl would be *so* much nicer if there was a way to automate pruning bounced "this person doesn't work here anymore" mails..
02:44 Kayden: mareko: thanks, I'd wondered whether those were supposed to rebind a subset, or bind some at a spot and invalidate the rest. good to know how it works now :)
03:03 Kayden: sigh
03:03 Kayden: I should probably just email mesa-maintainers and ask people to not ship Mesa 17.3 for i965.
03:03 Kayden: There has not been a single release that's worked.
03:03 Kayden: They have all been riddled with crashes and hangs.
03:04 Kayden: Even basic things like running emacs cause GPU hangs and X to crash.
03:04 Kayden: or desktop panels
03:04 Kayden: and, we've fixed all of the bugs
03:04 Kayden: but we cannot seem to manage to actually cherry pick things to a branch and ship them
03:05 Kayden: jekstrand: your CCS patches never made it to 17.3.x
03:05 Kayden: jekstrand: according to the 17.3.4 RC email, they caused regressions in compute shader piglit tests. which probably means we forgot to tag or pick some earlier fix.
03:32 imirkin: i've given up on sending patches to stable... just tell people to run HEAD.
03:32 imirkin: the process is too unpredictable and uncontrolled
03:33 imirkin: surprised to hear intel's having issues though... i thought it was centered around intel needs
03:41 airlied: I think I've learned one thing with stable processes, there's no such thing has a handsoff stable process no matter what anyone tells you :-)
03:41 imirkin: well -- not having a stable process is pretty hands off :p
03:47 airlied: but pretty useless to consumers :)
03:47 imirkin: can't win 'em all
04:17 Plagman: is anyone looking at the mesa test runs on lunarg? maybe these are useful for point releases
04:17 airlied: yeah I think xexaxo1 said he was
04:18 Plagman: ideally they'd be part of the promo process, because knowing about failures after the release is tagged isn't too useful
04:18 airlied: though I'm not sure if the stuff Kayden is talking about affects games or just if you use mesa 17.3 as your X.org glamor mesa
04:19 Plagman: yeah i would hope that any widespread crash in games would have been caught
04:19 airlied: well except vulkan ones :P, which was what tripped up 17.3.4
04:19 Plagman: yes
04:19 Plagman: working on that
04:19 Plagman: i think we should probably have one dedicated pair of eyes too, to turn data into bug reports
04:20 Plagman: since that involves reproing
04:20 Plagman: bisecting, etc
04:20 Plagman: before it's really useful to a dev
04:21 Plagman: and we only have 3 intel configs so i suppose it's possible we just missed it by not having the right hw
04:37 rmbeer: hello
04:37 rmbeer: anyone can helpme? i have problem for change the screen resolution, but unknown what problem have with the drivers or modules loaded: https://ptpb.pw/X_At.txt
04:37 rmbeer: command line: Xorg -nolisten tcp -extension Composite -extension GLX :1 vt2
04:40 imirkin: and what seems to be the problem?
04:41 rmbeer: imirkin, i can't change the resolution of the screen...
04:41 imirkin: why not
04:43 rmbeer: because everything is black and the LED light flashes. looking in the log the problem with drm appears...
04:43 rmbeer: https://pastebin.com/AS0QrKK9
04:44 rmbeer: It happens with all resolutions....
04:46 Kayden: airlied: yeah, mostly X, less games
04:46 Kayden: though, early 17.3 had the DRI3 threading bugs that led to crashes with fullscreen apps in general (which games probably could hit)
04:49 rmbeer: i unknown how to continue....
04:50 airlied: rmbeer: seems like a kernel bug on that kaveri. MrCooper might be able to help
04:50 airlied: can't etll what kernel you are running
04:51 rmbeer: 4.15.3-2-ARCH
04:51 airlied: okay seems modern enough
04:52 airlied: rmbeer: got the full dmesg?
04:53 rmbeer: wait..
04:54 rmbeer: airlied, https://ptpb.pw/-oJ4.txt
04:56 airlied: rmbeer: can you try using the non-vga outputs?
04:56 airlied: it has a vga bridge on it, and it seems like the driver might be driving it wrong
04:57 rmbeer: airlied, how to fix? and how known what outputs is non-vga?
04:58 airlied: rmbeer: dvi or whatever otheroutputs the motherboard has
04:59 rmbeer: VGA-1, is this only...
05:01 rmbeer: airlied, https://ptpb.pw/lk8Y.txt
05:04 rmbeer: Am I misunderstanding or am I giving the correct information?...
05:04 airlied: rmbeer: if the motherboard only has VGA you are hitting a driver bug that is causing the vga to be broken, I'm not sure I can help you get much further unfortunately
05:05 rmbeer: i use xf86-video-amdgpu, is correct or is wrong?
05:06 airlied: you are using the modesetting driver right now, amdgpu isn't being used on that card/kernel driver
05:06 airlied: but it doesn't look like a userspace bug, it looks like a kernel bug or maybe a bios bug
05:07 rmbeer: airlied, from the kernel, please...
05:07 rmbeer: with the bios you can not do anything....
05:08 rmbeer: I expected something better to solve the problem.... :(
05:09 airlied: I don't have any kaveri hw here so no way to reproduce
05:09 airlied: agd5f or MrCooper : might know if there are issues with nutmeg vga bridges on kaveri gpus
05:10 rmbeer: airlied, i no use kaveri gpu...
05:10 rmbeer: i use AMD A10-7860K Radeon R7, 12 Compute Cores 4C+8G
05:10 airlied: rmbeer: that's a kaveri
05:10 rmbeer: is a MB...
05:11 rmbeer: airlied, ok...
05:11 rmbeer: i see...
05:12 airlied: rmbeer: it might be worth trying to see if amdgpu.cik_support=1 radeon.cik_support=0 on the command line helps
05:12 airlied: it 'll switch to using another driver, though I can't think of any changes in that are
05:12 airlied: area
05:12 airlied: rmbeer: kernel command line
05:17 rmbeer: I better wait for MrCooper...
05:17 airlied: rmbeer: maybe getting a log with drm.debug=6 would help as well
05:31 rmbeer: "Kaveri" (2014)
05:31 rmbeer: -.-*
05:31 rmbeer: i buy the AMD in the last mouth of 2017
05:32 rmbeer: s/mouth/month/
05:38 airlied: glennk: I think i've crossed the streams alright, untangling bb creation from gcm and ra_split is fine
05:38 airlied: ^fine^fun
07:03 jekstrand: Kayden: That's very bad.
07:03 jekstrand: Kayden: We really need a process where, if I cc a patch to stable, it makes it there or else I get an email (other than the RC announcement) saying that they're having trouble with it and why.
07:03 jekstrand: And a chance to resolve it.
07:03 jekstrand: I'm tired of having patches not get into stable for mysterious reasons.
07:05 jekstrand: I should *not* have to read the stable RC announcement just to see if my patches made it in.
07:16 daniels: Kayden, jekstrand: i assume these issues were found by genuine humans rather than CI?
07:40 airlied: glennk: my r600-sb-move-gcm branch has the start of it, the big problem I'm facing is we don't create bbs for the movs to end up in, I'm not sure if I can just create bbs whenever I feel like it, or not
07:40 airlied: so far I'm trying to just create empty bbs anywhere a copy might show up
07:41 airlied: it passes the test that is causing all this, but fails on some nested loops, due to a missing bb
07:44 airlied:thinkgs that is tomorrow dave's problem
08:05 MrCooper: rmbeer: I can't suggest anything but trying the amdgpu driver using the command line parameters airlied wrote; agd5f might have other ideas
08:35 glennk: airlied, wondering a bit how that manages to pass since it'll still translate parallel phis naively into serial movs, or is it just lucking out on the order for that specific case?
08:48 xexaxo1: Plagman: I'm going through the LunarG results every time, before making the final release.
08:49 Plagman: nice, so the testing of rc's should be useful in theory
08:50 xexaxo1: Plagman: quite surprised that the RADV issue did not get flagged - will ask their team if they test it/can add a test
08:50 Plagman: it's unfortunate that vulkan still isn't being tested but hopefully that'll be fixed soon
08:50 Plagman: there's no vulkan tracing infrastructure yet
08:50 Plagman: it's just gl
08:50 bnieuwenhuizen: xexaxo1: There were CTS tests that failed with the release, just any of the releases got zero testing
08:51 bnieuwenhuizen: which is definitely what we're going to improve ;)
08:51 xexaxo1: bnieuwenhuizen: I dream of a magic CI that builds everything across distros (and platforms) and runs piglit, cts & others
08:53 xexaxo1: Plagman: ack, thanks for the confirmation.
08:54 xexaxo1: bnieuwenhuizen: out of curiosity: how long does CTS take on your end?
08:54 xexaxo1: *runtime
08:55 bnieuwenhuizen: about ~10 min if using my desktop and a custom runner for multithreading
08:56 bnieuwenhuizen: about half a day on some old HW
09:04 ivyl: nashpa: Can you verify that the patch, that was CCed to you, solves the problem? I just cheked it in libdrm_intel-less container.
09:23 danvet: meghana, did you figure out where the time is lost?
09:24 meghana: danvet: so my hunch was wrong, it doesn't seem to be because of dma_async
09:25 meghana: Martin replied on the thread
09:25 meghana: and he thinks that splitting in tinydrm is better than doing it in the core
09:31 danvet: meghana, ah right, just noticed the mails
09:31 danvet: I just figured it would be an interesting debug story to dig into where exactly the code hangs
09:32 danvet: it would be a neat way to learn about completions
09:39 danvet: meghana, wrt martin's comment that the driver should split, not the core, I think he didnt' entirely understand what we're doing
09:40 meghana: hmm yes, noralf replied to that, anyway in that case I'll still try to find out where it hangs
09:41 danvet: at least I thought the goal of doing this is that we a) remove a bunch of special-case handling code from tinydrm b) maybe make it a bit faster
09:41 danvet: and from my understanding I don't think we'll save any memory allocations by doing the chunking in tinydrm
09:43 airlied: glennk: ordering worls out
09:43 danvet: meghana, one more that just crossed my mind: when you send out a patch for feedback (because your stuck or want opinions or whatever) like with the spi one, add a [RFC] tag to the subject
09:43 danvet: and explain in the patch what's going on
09:44 danvet: for people who see the patch and not your private mail to noralf/me/sean it looks like your submitting a patch for merging, which is a bit confusiong
09:44 danvet:needs a new kbd, Enter is broken :-/
09:45 meghana: danvet, okay, maybe I'll resend the patch with the contents of the initial private email I had sent you, noralf and sean ?
09:58 eric_engestrom: danvet: in a pinch, ^M is [enter] :)
10:02 ivyl: at least everywhere wher it matters :P
10:08 danvet: eric_engestrom, I have the numpad one too :-)
10:09 ivyl: danvet: if you stretch a little bit than you can have it under your elbow
10:11 danvet: ^M mutes/unmutes in firefox :-/
10:11 danvet: and atm it's at the annoying 5% failure rate mode
10:12 danvet: mostly works, except when it doesn't and my brain freaks out about reality no longer obeying :-)
10:46 Booti386: https://patchwork.freedesktop.org/patch/196232/ someone?
10:49 eric_engestrom: mareko: you already reviewed ^, can you push it?
10:52 Booti386: Well, it does not apply anymore. Sorry
10:52 nashpa: ivyl: I have a similar fix, except it is a bit more thorough, it plugs the stubs/drm include_directories into every use of 'inc' in the lib/meson.build file
10:53 Booti386: Of course it does not apply, I applied it locally --'
10:53 nashpa: ivyl: ah, now I figured out what the magic trick was in meson to update that inc object :)
10:54 nashpa: ivyl: my change was more manual and added the array for every include_directories
11:03 ivyl: nashpa: can you share? I would like to see it as actual code :D
11:18 nashpa: ivyl: this is what I have: http://paste.debian.net/1011125/
13:05 xexaxo1: danvet, mupuf: been wondering if Xorg/SPI/Khronos cannot help out with Mesa's texture-float patent thingy https://cgit.freedesktop.org/mesa/mesa/tree/docs/patents.txt
13:05 xexaxo1: what's the process of bringing questions like these to board's attention?
13:05 mupuf: xexaxo1: send an email to board@foundation.x.org
13:06 mupuf: this is indeed possible that something could be done
13:06 xexaxo1: mupuf: will do, thanks.
13:06 mupuf: worst case scenario, we'll need to wait 5 more years
13:07 danvet: xexaxo1, what would you expect the board to do?
13:11 mupuf: danvet: IIRC, now that we are part of the kronos, if the patent holder is part of it too, then he cannot attack us for using his patent
13:12 mupuf: not sure if this is transitive to all users
13:12 mupuf: it is worth investigating, IMO
13:14 mupuf: not too sure how this would work if we were not to belong to Khronos again. I guess we would have to rip the code out again
13:14 bnieuwenhuizen: also does it matter adopter vs. member wrt those protections
13:15 mupuf: bnieuwenhuizen: probably, I will need to read the contract again
13:18 mupuf: there was a clause about patents which I did not pay too close attention to, given how many of them we own :p
13:21 danvet: mupuf, the code is included already
13:21 danvet: it's about using it
13:21 danvet: but yeah I guess we could ask spi and khr for clarification on this
13:22 mupuf: Oh right, i was thinking about libdxt or whatever its name is
13:22 danvet: that patent expired
13:23 mupuf: Nice
13:32 pmoreau: xexaxo1: Btw, the google link to the patent 404es. Maybe it should be replace by https://patents.google.com/patent/US6650327 instead?
13:32 pmoreau: *replaced
13:32 eric_engestrom: pmoreau: yup, just noticed the same; care to send a patch? :)
13:33 pmoreau: eric_engestrom: It would have to wait for tonight, as I’m at work and don’t have a clone of Mesa handy, nor git send-email configured for it.
13:33 pmoreau: So feel free to do it ;-)
13:34 eric_engestrom: I'll do that now then ;)
13:35 pmoreau: Thanks! :-)
13:38 pmoreau: At least I have my email set up and can review it. :-D
13:39 danvet: oh
13:39 danvet: reading that thing I'm not sure anymore exposing fp16 in the kernel is a good idea
13:39 danvet: the patent seems to be for the full pipeline
13:42 xexaxo1: danvet: email with some details - what/how/etc sent.
13:43 xexaxo1: hopefully one of the things mentioned will work out - hey perhaps SGI will just reconsider and grant an exception ;-)
13:44 eric_engestrom: should EGL_EXT_pixel_format_float be guarded as well then?
13:50 xexaxo1: eric_engestrom: the spec does not mention any IP 'problems' so I won't look too much into it
13:54 danvet: xexaxo1, I'm not seeing your mail yet on board@foundation.x.org ...
13:55 Booti386: What is graw?
13:56 xexaxo1: danvet: Message-ID: CACvgo53Aobox3wtSz5J1DhT=w8yufO21VbZPOKg1BPUWrtxREg@mail.gmail.com To: board@foundation.x.org
13:56 fredrikh: xexaxo1: they're an IP holding company now AFAIK, so not likely
13:57 xexaxo1: I'll give it a few minutes - the spam filter might be having fun with it
13:58 xexaxo1: fredrikh: indeed the wiki page is rather... ahem fun https://en.wikipedia.org/wiki/Silicon_Graphics#Graphics_Properties_Holdings,_Inc._era
13:59 xexaxo1: still some of my ideas work out - great. alternatively things will say as-is for another few years ;-)
14:00 xexaxo1: eric_engestrom: please rename the thread when hi-jacking it ;-)
14:05 eric_engestrom: xexaxo1: what thread?
14:06 xexaxo1: eric_engestrom: meson and BSDs - last few times the topic quickly became very heated.
14:06 eric_engestrom: haha yeah, I am currently writing a reply that I had to rewrite a couple times before sending to de-heat it ^^
14:06 eric_engestrom: basically my anser is: it's your own fault
14:07 xexaxo1: they know it pretty well.
14:07 xexaxo1: there's no point if rubbing salt
14:07 eric_engestrom: yeah, I think I might even just not answer :/
14:07 danvet: pinchartl, didn't we once discuss about bridge drivers and unload bugs and try_module_get?
14:07 danvet:just learned about device_link_add()
14:08 danvet: probably should sprinkle that over drm_bridge.c somewhat
14:11 danvet: imirkin, still didn't show up
14:12 eric_engestrom: xexaxo1: any objection that I push the pthreads patches (mesa & libdrm) now?
14:16 danvet: imirkin, ah it showed up now, I guess fd.o was stuck
14:40 robclark: danvet, re: fp16 in kernel, I think consensus seems to be that if the implementation is in hw, there is no problem to expose it. The i965 classic driver exposes texture-float by default (no compile-time switch to disable it).. the only reason the situation isn't similar for gallium drivers is that no one has untangled the build option to split hw and sw implementations..
14:40 imirkin: danvet: btw, what should i do about the XBGR thing? you were happy with it, vsyrjala wanted a vfunc ... i like my version since it's easy to backport (not to mention it's already written). i dunno how such things are normally resolved.
14:40 robclark: (ianal and all that, but I don't see how the situation is different from mesa)
14:43 danvet: imirkin, the current one has my r-b, imo that's good enough
14:43 danvet: I really don't think a vfunc for a backwards compat uapi hack is a good idea
14:43 danvet: way too much potential to abuse it
14:44 danvet: and rough consensus says that's good enough
14:44 danvet: adding the hack doesn't prevent us from adding a vfunc in the future
14:44 imirkin: ok
14:44 danvet: imirkin, you can also have my ack for merging through nouveau
14:45 imirkin: i'll check with skeggsb if he wants to push it, otherwise drm-misc it is.
14:45 danvet: assuming it shows up somewhat timely in airlied's tree
14:45 imirkin: [since i have no tree myself]
14:45 danvet: need commit rights to drm-misc btw?
14:45 imirkin: mmmm ... probably not a good idea
14:45 danvet: why?
14:45 imirkin: i don't do much kernel things
14:45 imirkin: only when they prevent me from doing 3d things :)
14:46 imirkin: and 99% of what i do is inside nouveau, this is a rare occasion
14:52 seanpaul:catches up on president's day danvet messages
14:53 danvet: seanpaul, yeah I eventually realized why no one from the US replied :-)
14:53 seanpaul: danvet: re: -fixes patches, <---- padovan
14:53 seanpaul: re backlight series, was busy last week i'll check into that now
14:54 seanpaul: re: outreachy desc, see above
14:57 danvet: oh padovan on irc ...
14:57 padovan: seanpaul: danvet: oh yeah, not sure about the context, but it seems time to new pull request
14:58 danvet: padovan, the other thing is rolling forward past -rc1 with drm-misc-fixes
14:58 padovan: I was waiting for dave to pull the previous one
14:58 danvet: that controls the automagic logic for for-linux-next
14:58 danvet: padovan, don't wait, just send him more stuff
14:58 danvet: and poke why it hasn't landed
14:58 danvet: airlied isn't entirely loss-free :-)
14:59 danvet: usually if he hasn't pulled within 1-2 days he forgot about it and you need to resend/ping
14:59 padovan: danvet: yeah, since we moved to MatterMost at colllabora I've been failing with IRC :)
14:59 padovan: danvet: okay, I'll keep that in mind in poke him actively then
15:00 padovan: I'll look for the pull request first thing in the morning tomorrow, busy for today already
15:03 danvet: seanpaul, what about outreachy desc?
15:03 seanpaul: busy, will look into it today
15:04 seanpaul: (sorry if that cryptic message caused unecessary scrolling)
15:09 MrCooper: robclark: I'm afraid it might not be that simple :( I thought the patent licences were specific to a (hardware, OS, ???) tuple
15:10 robclark: :-/
15:10 robclark: well, I guess at least for case of intel, if they are exposing it in mesa, then the intel+linux combo must be covered?
15:10 imirkin: fp16 scanout is covered by said patent?
15:11 imirkin: i thought it was in relation to texturing... or blending
15:11 robclark: imirkin, https://patents.google.com/patent/US6650327
15:11 danvet: imirkin, some of the claims include the display part
15:13 imirkin: "scan conversion" btw, is basically rasterization. not scanout.
15:13 imirkin: (i haven't read through all the claims yet)
15:14 robclark: danvet, anyways, I guess it can be left up to individual drivers/vendors to decide if they are sufficiently paid up on the extortion^Dlicensing fees
15:16 imirkin: wow, claims 17 and 22 are basically patenting... floating point.
15:16 robclark: "Furthermore, the prior art software emulation approach lacked a floating point frame buffer and could not be scanned out" :-/
15:16 robclark: yeah, it is a ridiculous patent
15:16 vsyrjala: one would think that if the hw implements it they have a license to use it. but common sense rarely applies to these things
15:17 imirkin: well, the license could be specific to making the hw, not to using it, for example
15:19 imirkin: does it last until 2018 or 2023?
15:20 robclark: iirc 2018
15:20 robclark: so a few more months
15:29 karolherbst: tarceri: okay, so there is one issue left with the lower_all_io = false thing. Now I get a load_output in shaders notbeing tess_ctrl ones
15:29 karolherbst: and I hit this path in tomb_raider shaders
15:31 danvet: imirkin, " a display screen coupled to the frame buffer for displaying an image according to the color values stored in the frame buffer;" is almost every claim
15:36 danvet: imirkin, robclark is it really worth the bother then?
15:37 robclark: I guess 4.17 won't be released by the time the patent expires, so probably not worth caring about
15:39 danvet: http://www.patentcountdown.org/ yeah we're not faster than 137 days :-)
15:49 imirkin: definitely not worth bothering :)
15:50 imirkin: and yes, they do cover the "display screen" thing, but it's coupled with a whole bunch of other stuff, never alone
15:51 imirkin: but they also patent all floating point math, as long as it's stored in memory, in claims 17 and 22, so ... shouldn't matter too much
15:52 imirkin: and curiously, i think swrast is ok. they talk about "rasterization circuit" a lot. depends how it's defined i suppose.
15:52 imirkin: [in case it's not obvious to all, IANAL]
15:58 cwabbott: imirkin: you have to take the logical AND of all the claims to determine if you're infringing, so no, they don't patent all floating-point math
15:58 karolherbst: tarceri: this is the nir of the shader: https://gist.githubusercontent.com/karolherbst/251cd2d467a758d66cdca0a8c3f12e0f/raw/1f258ae1bdfd27f8dbbce2cf5f7eff72f4407203/gistfile1.txt
15:59 eric_engestrom: danvet: do you maintain patentcountdown.org? or is it a coincidence that it happens to be currently tracking the patent we're talking about? :]
15:59 eric_engestrom: (if you do, there's a typo on the AKA line)
16:00 danvet: I don't maintain it
16:00 imirkin: cwabbott: iirc, each claim is independent (unless explicitly mentioning it's a dependent claim)
16:00 danvet: but yeah, looks like tex float is the last one
16:00 cwabbott: imirkin: well, i remember differently
16:00 imirkin: cwabbott: however each claim may have multiple clauses (like most of theirs do), and there it's the logical AND
16:01 imirkin: this is why sometimes a patent will have some claims invalidated, but the remainder "stay"
16:01 imirkin: this makes the patent weaker, not stronger... if it were the logical and, the fewer claims the better
16:03 danvet: http://www.waybetterpatents.com/how_to_read_a_patent.html
16:03 danvet: eric_engestrom, and yeah I spotted the typo too :-)
16:06 imirkin: i won't gloat... cwabbott is young and hasn't filed BS patents (i assume)
16:13 lfrb: ajax: I've fixed the build errors, updated branch is there https://gitlab.collabora.com/lfrb/xserver/ (rfc/2018-02/dri3-v1.1)
16:18 ajax: lfrb: thanks!
17:01 robher: padovan: I'm testing out the virgl fence series. I'm seeing something that looks like a ref counting issue. Are there any changes to the mesa side?
17:03 karolherbst: tarceri: nvm, I already fixed it: https://github.com/karolherbst/mesa/commit/2c4dba3e6c3a98050f86b70c7496b5100925b381
17:13 daniels: dcbaker: something really unfortunate i just discovered - if you build with egl and glvnd support, you generate an egl.pc which specifies -lEGL_mesa, completely breaking glvnd as anything linking with that will call directly into mesa
17:13 daniels: dcbaker: last i saw, the pkg-config support didn't allow you to pass arbitrary strings, so i'm thinking that it probably needs to go back to using egl.pc.in and configure_file() to generate the pkg-config
17:14 daniels: (or just not ship egl.pc when glvnd is in use really, but then libglvnd doesn't ship egl.pc ... sigh)
17:14 ajax: yeah, that needs to change.
17:14 dcbaker: daniels: shouldn't libglvnd ship the egl.pc and glx.pc?
17:15 ajax: it's a little awkward if it doesn
17:15 ajax: does, rather
17:15 daniels: well, yes
17:15 ajax: it means glvnd would also want to install all the headers
17:15 daniels: ajax: is there much of a reason why it shouldn't install the headers?
17:16 daniels: i mean, it already has the xml
17:16 ajax: daniels: marginally harder for mesa to add an extension ahead of glvnd re-importing the khronos xml
17:16 ajax: also that <GL/gl.h> is not currently a thing you can generate because lols
17:17 ajax: these aren't showstoppers, just annoyances
17:20 dcbaker: daniels: it looks like you can pass strings to libraries
17:20 dcbaker: in the pkg config generator
17:21 dcbaker: I'll send a patch
17:21 daniels: dcbaker: oh ok, that wfm then - thanks!
17:22 dcbaker: I just wrote a test meson build, but it's not documented that it works. I'll send a pull request for meson to add that to the documentation once we land a patch
17:25 robher: padovan: adding the 16ms sleep for "vsync" seems to fix it.
18:23 daniels: jekstrand: are the commits in my gitlab wip/dri3-v1.1 branch something like what you had in mind for the 'suboptimal' bools in egl/vk wsi?
18:24 daniels: it should be quite a bit more explicit what's going on now, and vk now also arms the logic when transitioning between flip<->blit
18:24 jekstrand:looks
18:25 jekstrand: daniels: Which commit am I looking at?
18:25 jekstrand:doesn't see suboptimal stuff
18:26 daniels: jekstrand: 9d4c1a99da6cdfea8ba47e46000e83164ecffdcc vulkan/wsi: Return VK_SUBOPTIMAL_KHR for X11 + e6fcd0d376c4d10f9d5686cdf4c0fcae01d06739 egl/x11: Re-allocate buffers if format is suboptimal
18:27 jekstrand: I don't see those in gitlab
18:27 jekstrand: Oh, wait, maybe I do
18:27 daniels: yeah, er, look harder :)
18:28 jekstrand: daniels: What exactly does SUBOPTIMAL_COPY mean?
18:31 daniels: jekstrand: 'this could've been a flip, but it was a blit because of an allocation mismatch'
18:33 jekstrand: ok
18:33 jekstrand: daniels: So, just to get this clear, I think we want to reallocate in two conditions: SUBOPTIMAL_COPY and flip -> !flip.
18:34 daniels: jekstrand: i can see the latter, and don't think there's much harm in forcing it regardless
18:34 jekstrand: Sorry, I'm just trying to enumerate the cases so I can determine if the code actually does them.
18:34 jekstrand: All this "armed" stuff confuses me.
18:35 jekstrand: But maybe I'm just easily confused. :)
18:35 daniels: no, it's fine; it does need a better commit message and perhaps a giant comment somewhere
18:35 daniels: reallocating on flip -> !flip i agree with you, on the grounds that you can probably always do something better if you don't need to care about the display
18:36 daniels: reallocating on suboptimal yes, sometimes. but if you _can't_ allocate in a way which satisfies the winsys for flips, you don't want to return VK_SUBOPTIMAL_KHR and have the user allocate every single frame. so ARMED is there as a very basic way to make sure that we don't get into these kinds of reallocation loops.
18:36 jekstrand: yeah
18:37 jekstrand: Here's a thought (which you are free to shoot down!):
18:38 jekstrand: Why not simply have a swapchain bool for "we optimized for flipping"
18:39 jekstrand: Then the condition becomes "if (mode == SUBOPTIMAL_COPY && !chain->optimized_for_flip) chain->suboptimal = true;"
18:39 daniels: when is chain->optimized_for_flip set?
18:40 jekstrand: And also "if (mode != FLIP && chain->optimized_for_flip) chain->suboptimal = true;"
18:40 jekstrand: And probably need to set a chain->wants_optimized_for_flip in there somewhere.
18:40 jekstrand: chain->optimized_for_flip would be set when we create the swapchain images or maybe as part of swapchain creation.
18:41 jekstrand: My thought is that we really have two states "optimized for flip" and "not optimized for flip". We need to track current state and desired state.
18:41 jekstrand: We may not even need suboptimal
18:41 jekstrand: Maybe we can just do "if (chain->want_optimized_for_flip != chain->optimized_for_flip) return SUBOPTIMAL"
18:42 jekstrand: and optimized_for_flip could be an enum for "modifier set" or soemthing like that.
18:42 jekstrand: daniels: Am I making sense?
18:42 daniels: broad strokes, yes - i'm just trying to mentally translate into how that'd actually work in practice
18:43 daniels: i think it'd require some more tracking, but meh
18:45 lrusak: daniels: from the other day gbm vs dumb buffers, both can provide dma buffers?
18:46 jekstrand: daniels: Maybe?
18:46 jekstrand: daniels: I could try to draft something if you'd like.
18:46 daniels: lrusak: yep, both can provide dma-bufs, but dumb buffers may _only_ work on software maps
18:46 daniels: lrusak: they might also work for EGL, but this is very very very very very very very not guaranteed
18:46 daniels: jekstrand: np, i'm drafting it up now
18:47 lrusak: as compared to what?
18:48 lrusak: ah
18:48 lrusak: EGL surface or just an eglimage?
18:49 jekstrand: daniels: Ok
18:50 robclark: anyone know what the deal is with https://hastebin.com/siqepedoda.pas ? I have hit that a few times now w/ meson build after git-pull..
18:51 ajax: robclark: if you're using both autotools in-tree build and meson subdir build, and the autotools build is older...
18:51 ajax: then the autotools generated files will be ahead of the meson ones in the -I path
18:51 robclark:hasn't used autotools build for a while
18:51 robclark: (and mostly used out-of-tree for autotools too)
18:52 daniels: lrusak: it's easier to phrase it like this: there is _only_ one way dumb buffers are guaranteed to work. that is: you allocate them, you mmap them, you only use cpu access to that mmaped area, you unmap, you create a kms fb from it, and you attach the kms fb to a plane (either directly or implicitly via a crtc). that's it.
18:53 daniels: lrusak: you _may_ be able to texture from a dumb buffer when you import it as an eglimage, and you _may_ also be able to render to it when you bind it to a renderbuffer ... but that's extremely not guaranteed
18:54 lrusak: hmm, ok, as far as I know someone has already tried this and succeeded
18:54 lrusak: using EGL_EXT_image_dma_buf_import
18:54 daniels: lrusak: as i say, it might work! it's just that the interface explicitly does not guarantee you that it will
18:55 lrusak: ok
18:55 daniels: lrusak: on some drivers it definitely _won't_ work, and if you file bugs about that, the response will be 'sorry, that's why you shouldn't use dumb buffers'
18:55 lrusak: gbm guarantees that it will work?
18:57 robclark: lrusak, I missed first part of conversation, but gbm will get you a buffer than can be used w/ gpu..
18:58 lrusak: yes that's just what I want to confirm :)
18:58 robclark: (assuming that is what you were asking)
18:58 lrusak: and what are the gbm bo flags doing? GBM_BO_USE_RENDERING, GBM_BO_USE_SCANOUT, etc
19:00 daniels: lrusak: RENDERING is something you can use as a target for EGL rendering (via EGLSurface or EGLImage + renderbuffer); SCANOUT is something you can display with KMS
19:00 daniels: you probably want both
19:00 robclark: basically telling the gpu driver how you want to use the buffer so it can pick something that works
19:01 lrusak: SCANOUT should be used even when using an eglimage and glEGLImageTargetTexture2DOES ??
19:04 lrusak: also, is there a linux interface that tells me about dmabufs? allocation, etc?
19:07 lrusak: another question, in kmscube I don't see that they actually close() the fd from the gbm_bo. Do I need to use close(fd) or does gbm_bo_destroy take care of that for me?
19:11 pinchartl: danvet: I think we discussed it, yes. I don't think we have reached a conclusion though, but there's clearly a problem
19:12 pinchartl: we should I believe minimize the call to module_get() and only use it where absolutely needed. it shouldn't be a poor man's solution to lack of object lifetime management in the DRM core
19:12 pinchartl: (a.k.a. the devm_kzalloc() problem)
19:13 daniels: jekstrand: completely untested: https://hastebin.com/agatogogel
19:14 daniels: jekstrand: i'm leaning towards that probably being a net improvement; if that's something like what you had in mind, let me know and i'll split and type that up into proper commits etc when i get home
19:14 jekstrand: daniels: hastebin fail
19:15 jekstrand: I can't see it
19:15 daniels: lrusak: yes, they are bitmasked; in your case you want to render to it with egl (GBM_BO_USE_RENDERING), and you then want to display it using KMS (GBM_BO_USE_SCANOUT), so you pass both flags
19:15 daniels: jekstrand: lol, git diff vs. git show. https://hastebin.com/jucituwohi
19:15 daniels: lucky i hadn't actually left :)
19:15 daniels: jekstrand: (also pushed it to gitlab if you'd prefer to pick it up that way)
19:17 daniels: jekstrand: pretty sure that could benefit from static bool chain_is_basically_ok(struct x11_swapchain *chain) { return (chain->status == VK_SUCCESS || chain->status == VK_SUBOPTIMAL_KHR); }
19:19 robclark: ajax, hmm, so we have both include/GL/internal/dri_interface.h and $builddir/include/GL/internal/dri_interface.h .. which are different.. first which is still under version control..
19:19 jekstrand: daniels: Yeah, that seems like more-or-less what I was thinking.
19:20 daniels: jekstrand: ok cool, i'll do that up properly later
19:20 jekstrand: daniels: Yeah, though maybe chain_has_error would be a better name/semantic. :)
19:20 ajax: robclark: we what
19:20 daniels: robclark: i don't have the $builddir one ...
19:20 jekstrand: daniels: And you can do chain->status >= 0 :-)
19:20 daniels: jekstrand: chain_has_error == VK_SUCCESS seems a bit perverse :P
19:20 jekstrand: daniels: VkResult is expressly designed so that errors are negative
19:20 jekstrand: And SUBOPTIMAL is not an error
19:21 daniels: jekstrand: oh right, you mean for the helper function - yeah, that's fine
19:21 daniels: all fine by me
19:22 robclark: daniels, ajax, hmm, odd, I wonder where the $builddir one comes from.. deleting it seems to fix build..
19:22 robclark: oh, I see what is going on..
19:23 robclark: so I'm using $builddir as the install dir too
19:23 robclark: and ninja -C $builddir install
19:23 robclark: and since path for that header is same in builddir and installdir it picks up old one
19:23 ajax: naughty
19:29 robclark: lrusak, oh, and if you didn't figure out by now, caller owns the fd returned by gbm_bo_get_fd() (ie, you need to close()).. kmscube probably doesn't bother since it will be freed when process exits
19:31 lrusak: thanks :)
19:35 robclark: lrusak, there are some comments about the API, but all in $mesa/src/gbm/main/gbm.c .. not sure if that ends up in some generated docs somewhere, otherwise I guess it helps to have mesa src code
19:36 lrusak: yea I've had a brief look over
19:36 lrusak: seems I'm on the right track with what has been said already :)
19:38 robclark: cool :-)
19:44 airlied: padovan: I deliberately didn't pull the last one due to it having a base that was going to make my history ugly just before a merge, but yeah then I forgot :)
19:49 Jasper: Does mesa support any way of discovering the amount of VRAM? Similar to ATI_meminfo?
19:49 Jasper: I know this number effectively makes no sense but we use it for heuristics all across our engine. One thing I eventually want to potentially rip out but having a guess would be better than nothing.
19:49 ajax: Jasper: https://www.khronos.org/registry/OpenGL/extensions/MESA/GLX_MESA_query_renderer.txt
19:50 Jasper: Cool, thanks
19:50 ajax: even already printed in glxinfo
19:50 airlied: it also has ATI_meminfo :-)
19:50 ajax: (don't parse glxinfo output if you know what's good for you)
19:51 ajax: yeah, the mesa one is a little more informative iirc
19:52 airlied: though not sure we expose ATI_meminfo outside of the amd driers
19:52 Jasper: Yeah, Intel machine here
19:52 airlied: intel machines have no vram so it's easy :-)
19:53 agd5f: airlied, we also support the NV extension as I recall
19:53 agd5f: at least in gallium
19:53 Jasper: You know what, I'm going to try giving a terabyte of vram and see what breaks.
19:53 ajax: hm. on which gpus does PIPE_BIND_SCANOUT give you a slower-to-render-to format?
19:54 airlied: ah yes NVX_gpu_memory_info
19:54 ajax: (i know the answer is "probably most of them", i'm hoping to know more than that)
19:54 HdkR: Jasper: Dealing with residency without knowing how much vram you have must be a pain :P
19:54 airlied: ajax: most amd I hink
19:54 airlied: ajax: vc4 possibly
19:54 Jasper: Some GPUs can't even render to linear formats, can they?
19:56 imirkin: ajax: i'd imagine everything. scanout == linear, usually.
19:57 ajax: just thinking glamor mostly allocates with GBM_BO_USE_SCANOUT and mostly doesn't need to
19:57 imirkin: although maybe it's not slower to render to a linear surface, just texture from it. dunno.
19:57 airlied: amd has tiled scanout, just different tiling format
19:57 ajax: if you don't have any outputs the same size as the pixmap then you _probably_ don't need to be able to scan out of it
19:58 Jasper: HdkR, I was a bit shocked to see glAreTexturesResident in an old codepath. Thankfully, it's unused.
19:58 HdkR: hah :D
20:00 Jasper: I'm nearly certain all the heuristics we do on vram heap sizes are basically all junk on non-console platforms.
20:01 HdkR: Probably
20:02 agd5f: we can certainly scan out of tiled buffers, but PIPE_BIND_SCANOUT may imply sharing which would end up as linear
20:02 imirkin: it's tough, both for the application and the driver
20:02 imirkin: e.g. nouveau will try to do a flush when the size of the used resources in the accumulated batch hits x% of vram
20:02 imirkin: (like 90 or something)
20:02 airlied: it's probably good to know you have a 1GB vs 8GB card, but if you are on Intel not sure what is best
20:03 airlied: you are going slow anyways :-P
20:03 Jasper: ajax, also, update: I managed to try that patch to libX11, it didn't help.
20:03 Jasper: Things appear to be stalling in xcb_wait_for_special_event, not _XReply anyway.
20:04 Jasper: Also, how does DRI3 decide whether to allocate PIPE_BIND_SCANOUT or not? Heuristics based on matching output / monitor size? Always?
20:05 ajax: always.
20:05 Jasper: oof
20:06 ajax: or rather: by the time you make a pixmap shared, a scanouttable pixmap will be allocated if it needs to be
20:06 ajax: see glamor_make_pixmap_exportable()
20:07 Jasper: If we're talking about mesa backbuffers though...
20:08 imirkin: backbuffers have a nasty habit of becoming frontbuffers
20:09 ickle: at the most inconvenient of times
20:12 Jasper: well, in theory not all front buffers need to become scanout BOs
20:12 HdkR: imirkin: Theoretically if you're becoming bandwidth bound then a linear buffer could harm you I guess? :)
20:13 imirkin: HdkR: if you render to it once and don't texture? dunno if that's actually the case.
20:13 HdkR: You'd lose the compression benefits with linear as well though right?
20:15 HdkR: Which I guess could also effect cache usage depending on tiling...
20:16 HdkR: but still stores, so not the largest impact. When you do readbacks are when the real pains come to play :D
20:20 mareko: Jasper: I recommend using GL_NVX_gpu_memory_info
20:21 Jasper: Doesn't appear to be on this machine.
20:21 mareko: or GLX_MESA_query_renderer
20:21 mareko: they are supported by radeonsi at least
20:21 Jasper: For now I just hardcoded it to assume 4GB of VRAM. Seems good enough.
20:21 mareko: GL_ATI_meminfo doesn't show total memory, only free memory
20:21 danvet: pinchartl, ah right, that was in context of devm
20:22 Jasper: ah
20:22 danvet: device_link_add should help with the module_get+driver_get (which isn't really a thing) for components (like bridge, panel, ...)
20:26 pinchartl: danvet: how does it help ?
20:27 pinchartl: I thought it mostly handled power management
20:27 pinchartl: (as in suspend/resume ordering, and optionally runtime PM)
20:28 pinchartl: (there was also a plan to use the information to order device probing in a way that minimized probe deferral but I don't know whether that has been implemented)
20:37 danvet: pinchartl, it also makes sure the driver is bound and stays bound
20:37 danvet: apparently on by default, but can be disabled
20:37 danvet: per the docs at least
20:37 danvet: you probably still need to do some deferred probe magic at load time
20:39 pinchartl: that sounds dodgy to me
20:39 pinchartl: you can't force a device to stay bound to a driver in the general case as the device can be removed from the system
20:40 pinchartl: (think hotpluggable devices)
20:40 pinchartl: are you referring to " The consumer devices are not probed before the supplier is bound to a driver, and they’re unbound before the supplier is unbound." ?
21:04 airlied: pinchartl: could I ask for at least a one or two line summary in a pull req email
21:05 airlied: pinchartl: even if it's just misc fixes, for this one I'm going with LVDS startup fixes enable VSP compositor on gen3
21:05 airlied: anything I can cut'n'paste into the merge commit is better than me writing it :-P
21:08 pinchartl: airlied: sure
21:08 pinchartl: should I reply to the e-mail I sent you, or provide a summary for the next pull requests from now on ?
21:09 airlied: pinchartl: from now on is fine, I just wrote a one liner for it
21:09 pinchartl: thank you
21:10 pinchartl: if I forget next time please push back on the pull request
21:10 pinchartl: I'll try to remember
21:10 pinchartl: robher: I'm trying to locate the patch you referred to from Pantelis (to add a new OF property). would you happen to remember the subject line ?
21:10 pinchartl: robher: scratch that, I saw your reply
21:11 airlied: padovan: pulled the cirrus lut branch into drm-fixes now
21:12 robher: pinchartl: I'm fine if you just lift the one function you need or move your implementation.
21:13 pinchartl: robher: it's a big patch series to pull in as a dependency for just the change I need...
21:14 robher: pinchartl: right. It only had minor changes needed at the time and I was willing to take it without users, but then Pantelis never got back to it (a common pattern...).
21:15 pinchartl: I don't think I have enough knowledge to judge whether the whole patch series still makes sense
21:16 pinchartl: I could possibly extract the property functions from patch 2/5
21:16 pinchartl: leaving of_changeset_create_device_nodev() and of_changeset_create_device_node() out
21:17 pinchartl: that would be more or less self-contained
21:19 karolherbst: any suggestion on how to add support for native texturegatheroffsets support in NIR?
21:19 karolherbst: I know that the tex instructions have sources typed, and that we have one nir_tex_src_offset for the offset
21:19 Booti386: mareko: Sorry, i forgot to cc you for this one https://patchwork.freedesktop.org/patch/205613/ (it's not like it's a tremendous change, but...)
21:19 karolherbst: but we can't really put an array of offsets into it
21:20 karolherbst: so I am thinking to just add more types like nir_tex_src_offset1, nir_tex_src_offset2...
21:20 imirkin: Booti386: that doesn't help you though, right?
21:21 pinchartl: robher: as far as I can tell from patchwork there were only two minor comments. I can easily fix them and resubmit if that's preferred, but I'm not sure it's worth it
21:21 pinchartl: especially if the main goal is to make struct property opaque at some point
21:22 pinchartl: in that case only the property helpers would be needed
21:22 pinchartl: also, would you be fine merging that patch through the DRM tree ? I'd like to get the whole patch series in v4.17
21:23 Booti386: imirkin: No, I'm just trying to understand how everything work, so i do some kind of cleanup bit in the meantime
21:23 imirkin: sure ok
21:25 robher: pinchartl: yeah, we do want to make struct property and struct device_node opaque eventually. No problem merging it thru DRM or I can provide a stable branch.
21:28 pinchartl: robher: ok, I'll take patch 2/5 only then and strip out the non-properties parts
21:28 pinchartl: I'll leave it up to you to revive the other patches
21:29 pinchartl: although I assume I'll need to add a test case ?
21:33 robher: pinchartl: Yes, please. There's already one there, so it may be easier to just take everything.
21:34 pinchartl: robher: you're annoying :-)
21:34 pinchartl: I'll see what I can do
21:35 robher: pinchartl: that's what I'm here for.
21:36 robher:BIAB
21:41 bwidawsk: airlied: any plans for EGL export with modifiers?
21:43 daniels: bwidawsk: ugh
21:43 daniels: bwidawsk: just use gbm to allocate and import instead
21:55 bwidawsk: daniels: did we never make an API to get the selected modifier?
21:55 bwidawsk:doesn't see it
21:56 daniels: bwidawsk: where?
21:56 bwidawsk: src/gbm/main/gbm.h
21:57 daniels: 'get the selected modifier'?
21:57 bwidawsk: whichever modifier the implementation chose
21:57 daniels: what for? gbm_surface is the only place i can think of it missing, but then you get it from gbm_bo
21:58 bwidawsk: the client?
21:58 danvet: pinchartl, *cough* dim would remind you to type the pull summary and script it all *cough*
21:59 daniels: bwidawsk: which client?
21:59 daniels: bwidawsk: do you mean that there should be a gbm_surface_get_modifier()?
22:00 bwidawsk: I'm just trying to figure out how to import a buffer to CL (or maybe VAAPI) created in mesa with a modifier associated with it
22:05 pinchartl: danvet: getting there, getting there :-)
22:08 daniels: bwidawsk: allocate with gbm in the first place :)
22:09 daniels: bwidawsk: i mean - you won't have an fd/name to import until you have a gbm_bo, and at that point you can get the modifier from the bo, right?
22:12 mareko: Booti386: sorry I'm not able to tell if the patch is correct
22:13 Booti386: Well... Ok :)
22:13 mareko: I might apply it and run piglit later
22:15 Booti386: Ok, thank you :)
22:27 karolherbst: anybody a better idea regarding support for tg4 with 4 offsets? vec4 32 ssa_25 = tg4 ssa_24 (coord), ssa_45 (offset), ssa_46 (offset1), ssa_47 (offset2), ssa_48 (offset3), 0 (gather_component), 0 (texture) 0 (sampler)
22:29 padovan: airlied: thanks, I'll send another -fixes pull request tomorrow :)
22:40 bwidawsk: daniels: you mean a gbm_surface?
22:41 bwidawsk: I don't see anything stored for a gbm_bo
22:43 daniels: bwidawsk: gbm_bo_get_modifier()
22:44 bwidawsk: daniels: that's what I was asking about originally :-)
22:44 bwidawsk: thanks
22:44 bwidawsk: I couldn't find that damn function for some reason
22:44 daniels: bwidawsk: haha, didn't you write it?
22:45 bwidawsk:shrugs
22:45 bwidawsk: damn
22:45 bwidawsk: I did
22:45 bwidawsk: I remembered it existed at least
23:04 imirkin: question to someone who knows how KHR operates... are VK-GL-CTS pull requests reviewed on some schedule? ad-hoc? do i need to ping someone?
23:07 airlied: imirkin: there's a meeting, it might not have happened this week
23:07 airlied: or it's tomorrow
23:07 imirkin: ok, so in theory there's a weekly meeting, and outstanding pull requests are reviewed there?
23:09 airlied: I'm not sure anyone looks at public pull reqs :-P
23:09 imirkin: mine's been pending for 10 days, so at least 1 meeting must have gotten cancelled if that's the case
23:09 imirkin: oh
23:10 imirkin: do you know who runs the meetings usually? or someone i should ping on github?
23:10 airlied: the minutes from the last meeting look sparse
23:10 airlied: which suggests it might not have happened
23:11 imirkin: ok. i'll give it until next week then.
23:11 pinchartl: robher: you've got mail