00:01anholt: I'm not sure that the time savings we're talking about here is worth the complexity. I'd be more interested in what compiler tunables there might be to get us "symbol backtraces, maybe function input values if they're cheap" rather than a full most-debuggable binary.
00:03anholt: given how allergic most mesa devs are to thinking how to interact with the CI already, making any additional complexity for debugging makes it less and less likely that anyone ever uses it.
00:03DavidHeidelberg[m]: anholt: when transferring outside of us and network is under load, sometimes the transfers are really slow, so every MB seems to matter (in terms of performance).
00:03DavidHeidelberg[m]: *US
00:04DavidHeidelberg[m]: btw. with the docs ( https://mesa.pages.freedesktop.org/-/mesa/-/jobs/34548032/artifacts/public/debugging.html#working-with-core-dumps-generated-by-ci ) it doesn't seems to be so hard to setup with few commands and debug. It's in general normal coredump
00:08anholt: why is the debug.dwp not included in the unstripped mesa tarball?
00:09DavidHeidelberg[m]: anholt: because of otherwise it have to be linked with linker at compilation time, which would slowdown the build
00:09DavidHeidelberg[m]: so in unstripped build are only references to the debug.dwp (exactly to the .dwo files inside the .dwp)
00:17anholt: we're linking debug info at compile time today, right?
00:17Lynne: have to say, descriptor buffers are so much nicer to work with
00:21DavidHeidelberg[m]: anholt: with my MR we can use split-debug (so not put debug into .o, but .dwo), otherise sure
00:22anholt: I'm trying to understand why you need the split-debug complexity for the unstripped tarball.
00:23DavidHeidelberg[m]: anholt: in general, this page sums it up https://gcc.gnu.org/wiki/DebugFission ; for smaller project it doesn't matter, but Mesa is already large enough to difference to be seen
00:23anholt: (I haven't done the work myself, but I really suspect there's something better we could choose in our debugoptimized build's -g options that could make the cost of debug symbols low enough that it would give us debuggability without extra tarballs even)
00:25DavidHeidelberg[m]: anholt: well, even with full debug with debugoptimized it's not perfect since we lose all details, I assume doing something between would produce very limited results (not saying it couldn't produce something useful ofc)
00:26DavidHeidelberg[m]: I used mine MR few times and I had to say I would prefer to have meson 'debug' build, but ofc that's useless for flakes.
02:43karolherbst: uhh... why can't I trigger the fails CI runs into locally :(
07:47daniels: karolherbst: which driver?
08:36linkmauve: “23:28:30 gfxstrand> IDK, Intel has managed to evolve their hardware for 15 years without deleting interesting formats.”, /me cries in ASTC.
08:57MrCooper: DavidHeidelberg[m]: FWIW, -ggdb/-ggdb3 might improve debugability of debugoptimized builds, probably at the cost of bigger debuginfo though
09:57HdkR: linkmauve: Everyone cries in ASTC, just like the hardware designers
10:04karolherbst: daniels: llvmpipe mainly
12:34DavidHeidelberg[m]: MrCooper: sounds good, anyway I don't see -ggdb vs -ggdbX documented in GCC docs
12:39psykose: it's in the manpage
12:39psykose: the documentation doesn't say anything useful however
12:40psykose: you can grep ggdb here https://man7.org/linux/man-pages/man1/gcc.1.html
12:40psykose: it just repeats the same shit as -g
12:41psykose: unsure if it does anything at all
12:44psykose: output size is the same though the sha changes
12:44psykose: maybe what i built is just not reproducible
12:44psykose: as for ggdbX it's in the ggdblevel part
12:45psykose: -g3 -> ggdb3 -g2 -> ggdb2
13:18karolherbst: where can I check what CTS version/tag a test is using?
13:18karolherbst: or is it all the same?
14:07karolherbst: I'm now even on the same CTS version and can't trigger the fails from CI :(
16:13DavidHeidelberg[m]: hakzsam: I suppose you don't have Helen Android patches included in the VKCTS uprev, right?
16:13hakzsam: nope?
16:14DavidHeidelberg[m]: There is few patches included in Helen tree which cannot be upstreamed yet, if you apply them it would be best
16:15hakzsam: I will try to remember, thanks
16:27emersion: can someone review this? https://patchwork.freedesktop.org/series/109887/
16:27emersion: just simple logging stuff
16:28karolherbst: okay.. so my MR regresses stuff, just not on my machine :'(
16:36karolherbst: this makes no sense...
16:37karolherbst: gfxstrand: any idea how https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20161/diffs?commit_id=e908e08deb198153d92075889815192edb12eb30 could break OpenGL? I honestly don't see a path to this code from a GL perspective
16:37sewn: is this the right channel to ask for mesa compiling help? im experiencing a weird mesa build failure.
16:41karolherbst: oh uhhh....
16:42karolherbst: oops
16:42jenatali: wael: Yeah, probably
16:44soreau: sewn: yes
16:44sewn: despite zstd being disabled via -Dzstd=disabled, libvulkan for amd drivers attempt to link to it, which causes a build failure
16:47soreau: is this with mesa git or a release?
16:47karolherbst: I think I found it...
16:47sewn: it also attempts to link to udev, which in the manually specified (variable, -Dpkg_config_path meson option) pkg config paths, it tries to link to it as well.
16:47sewn: release 22.3.5
17:56gfxstrand: karolherbst: Uh... what?
17:56gfxstrand: Yeah, that makes no sense.
18:19DemiMarie: jenatali: what does “crash” mean in this context? If it means that the kernel driver or GPU firmware crashed, that is a bug in the kernel or GPU firmware.
18:19jenatali: It means that the GPU hung, which can also indicate a bug in the usermode driver generating commands that would hang the GPU, or a bug in an app
18:24bestest: I'm suffering startup crashes on mesa for the game Minit, which uses 32-bit YoYo Games Linux Runner 1.3 and appears to suffer from the issues described here https://gitlab.freedesktop.org/mesa/mesa/-/issues/1310 https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4181 . As far as I can tell, these issues were fixed 2 years ago, but I'm on the latest stable for mesa and the game still crashes. Was there a regression, or was the
18:24bestest: issue never properly fixed, or am I simply doing something wrong?
18:27eric_engestrom: sewn: that's really weird; the code that handles this is simple enough that I'm sure there's no bug in it:
18:27eric_engestrom: https://gitlab.freedesktop.org/mesa/mesa/-/blob/mesa-22.3.5/meson.build#L1597
18:27eric_engestrom: zstd is replaced with an empty dependency if you pass `-D zstd=disabled`, so anything after that will never even know zstd is a thing
18:28sewn: just to be sure, im building this with lib32 in mind, and pkg config path is set to /usr/lib32/pkgconfig
18:30bestest: Well, it does crash; is there any info I can provide that would help?
18:30bestest: I tried to get a backtrace, but it just returns no stack
18:31bestest: Oh, I'm sorry, I misread, my apologies
18:39soreau: sewn: have you tried removing the build directory and trying again?
18:40sewn: im building it with a package manager, so technically yes
18:40eric_engestrom: sewn: that shouldn't make any difference with that; it might not find things or find things it can't use if the lib32 config is missing/wrong, but that's it
18:40sewn: eric_engestrom: it says udev is found but is not actually in pkg config path
19:02karolherbst: gfxstrand: yeah... I still have no idea, but apparently my new version changes things and I replaced `deref->var->type` with `deref->type`...
19:02karolherbst: and now the llvmpipe CI tests aren't failing anymore
19:02karolherbst: or rather.. randomly crashing
19:02karolherbst: I still have no idea how that path is even hit..
19:03jenatali: Yeah deref->var would only be valid for direct variable derefs, but if you've got arrays, it wouldn't be set
19:07DemiMarie: jenatali: are GPUs generally unable to prevent malicious userspace from freezing them?
19:07jenatali: In my experience, yes
19:07DemiMarie: Is this because of the lack of instruction-level preemption?
19:08jenatali: Effectively, running a shader on the GPU is kind of like running a userspace process. Someone authored the shader code. If it does something like dereference a null pointer... it's got to crash somehow
19:08jenatali: Some GPUs can report those types of errors, others just hang
19:09jenatali: That's about the extent of my knowledge though
19:09DemiMarie: I expect the shader to crash, but it should not take down other stuff on the GPU.
19:10jenatali: Right. Newer GPUs don't have to take down the whole GPU, that particular program would just hang, and then the host OS can reset the engine and set the GPU to work on a different task
19:11DemiMarie: This is especially important for VR/AR where a malicious shader must not be able to prevent the VR/AR from updating, as otherwise the human user might get sick.
19:11gfxstrand: karolherbst: Oh.... Yeah, deref->var->type wasn't going to work
19:12karolherbst: yeah.. but I'm more confused on how llvmpipe even hit that path...
19:13karolherbst: I think I still have a regression with AMD, but I can figure out what's wrong there...
19:13karolherbst: all arb_bindless_texture related, which kind of makes sense *sigh*
19:25neko2: whoops of course I forgot nick reg
19:25neko2: hey all. I've encountered a rather nasty amdgpu reset/crash loop today that I can trigger pretty reliably. wondering if this the right channel or if I need to direct it somewhere else... memory is fuzzy but I'm sure it was dri something or another.
19:27karolherbst: neko2: probably just want to file a bug on gitlab or something, but there is a #radeon channel for more AMD specific things
19:28neko2: right, I feel like it is more of a kernel thing anyway. yes there is a crash triggered by a program which I've yet to get to the bottom of, but there is this loop of reset fails on top.
19:28karolherbst: ohh it's more of a hardware thing
19:28neko2: I suspect sp
19:28neko2: *so
19:28neko2: I already think this hw is cursed tbh
19:28karolherbst: the hardware doesn't really support fault recovery, so all the kernel can do is a full GPU reset
19:28karolherbst: and often that doesn't go as well
19:29neko2: shall I just upload the dmesg somewhere so you can see if it's one of those such cases
19:29karolherbst: _but_ ultimately it's also Userspace sending faulty commands to the hardware
19:29karolherbst: mhh
19:30karolherbst: yeah, I guess it makes sense to file a kernel bug, but also a mesa bug (if it's triggered throguh GL/VK(
19:30karolherbst: Userspace obviously shouldn't send garbage, but the kernel should also handle recovery better
19:30neko2: in this case the offender was libreoffice of all things
19:31neko2: I can only survive if I disable it's acceleration
19:31karolherbst: mhh
19:31neko2: here is the log https://paste.rs/peC
19:31karolherbst: acceleration through OpenCL by any chance or general acceleration?
19:31neko2: I think general GL
19:31neko2: it didn't get past the splash screen
19:31neko2: it'd hang, a ring timeout would fire, the reset loop would happen for a while
19:32neko2: eventually it gives up and hangs on something else, and after that I lose system responsiveness
19:32karolherbst: yeah.. if the GPU keeps getting broken command it will just crash again
19:33neko2: huh. but the kernel can identity it's soffice.bin. surely if a crash occurs the best thing is to punt the offender
19:33neko2: obv I'm not a kernel dev
19:33karolherbst: mhh, not really, or at least that's not what people would like to do
19:33neko2: well I mean it's standard for userspace
19:33neko2: you segfault, you have a bug, your results are meaningless
19:33neko2: you get murdered
19:34karolherbst: sure.. but it could also just reap the userspace process if it keeps crashing multiple times
19:34karolherbst: doesn't have to check the process name
19:34karolherbst: anyway.. there are multiple bugs to be fixed :)
19:35neko2: in any case, I already expect my hardware doesn't help with the recovery process, given that it's raven ridge on a quirky motherboard
19:35karolherbst: newer GPUs aren't better
19:35neko2: still, I have encountered enough bugs at this point to know this combo is a source of curses
19:35pixelcluster: neko2: it indeed starts out looking like a relatively "normal" gpu hang ("ring comp_1.1.0 timeout")
19:35karolherbst: well.. newer AMD gpu's
19:35pixelcluster: the recovery seems *really* cursed though, I never saw it fail like that
19:35karolherbst: some vendors care more about GPU resets, some.. don't
19:35neko2: karolherbst: yeahhhhh ngl as much as I hate it, think my next system will be team blue gpu
19:35pixelcluster: karolherbst: well it can work
19:36karolherbst: well, yes... but you have to reset the entire GPU
19:36neko2: pixelcluster: like I said. I think asrock have fucked several things in this firmware
19:36karolherbst: others aren't that cursed
19:36pixelcluster: it does work quite well on the steam deck
19:36neko2: ... wait heck, language check, rip
19:36karolherbst: yeah.. not saying that it doesn't work most of the time
19:36neko2: (sorry. I'll keep the f-strikes tactical but I think that one was deserved, this bios is truly awful in many ways)
19:36karolherbst: but I've seen it fail miserably and also seen it recovering properly
19:37pixelcluster: I think that is because recovery is better tested in the kernels they ship
19:37karolherbst: nah.. not all people are from the US here :P
19:37neko2: like to get this far with the crash loop, I had to disable iommu beecause this firmware's handling of this is likely broken based on looking up those crash logs (I don't have those sadly, something broke in saving the logs)
19:37neko2: it would fail on even the first reset otherwise
19:37pixelcluster: rip
19:38neko2: so that doesn't bode well
19:38karolherbst: mhh I can also imagine that enabling iommu makes things worse, because I don't think any developer tests with iommu enabled tbh
19:38neko2: side note: iommu.strict can be ignored in the cmdline, I had left that there but at this point I disabled it in firmware due to being broken on this system
19:38karolherbst: well.. can always file bugs
19:39neko2: not actually sure where to start with the crash loop filing that
19:39neko2: where do I even file a bug for amdgpu's kernel side
19:39karolherbst: good question
19:39neko2: even if they tell me "your hardware is screeeeewed"
19:40karolherbst: https://gitlab.freedesktop.org/drm/amd/-/issues
19:40neko2: (I do suspect a 50% chance of this at this point)
19:40karolherbst: I mean.. it's their hardware, they probably know it's screwed
19:40karolherbst: :P
19:41karolherbst: but yeah.. in 95% of the cases where hardware is blamed, it's actually a software bug
19:41neko2: well when I say hardware, I mean the firmware intimately tied to it
19:42neko2: there were a few flags reading it that suggested something terribly wrong was occuring at a low level
19:42karolherbst: maybe
19:42karolherbst: but that doesn't really matter for GPU resets
19:42neko2: oh? I was under the impression the firmware had to be in cooperation to reset properly...
19:42neko2: at least as far as the primary GPU is concerned
19:43karolherbst: the GPU's firmware yes, but not really the motherboard one
19:43karolherbst: once you are in your OS the firmware doesn't really do much with the GPU anymore
19:43neko2: right. well, it's an integrated one, on a 2200G, so I doubt there would be weird firmware for it...?
19:43karolherbst: yeah and even if.. the driver has to deal with nasty GPU firmware
19:44karolherbst: OEMs usually get tools from nvidia/AMD to customize the GPU firmware, but that still follows rules
19:45neko2: just trying some keywords in the search atm to look for dupes
19:46jenatali: Why are apps awful...
19:46karolherbst: because they are written by humans :P
19:47jenatali: GFXBench apparently hardcodes VK_FORMAT_A2R10G10B10, which is optional, when they could just as easily use VK_FORMAT_A2B10G10R10, which is required
19:47karolherbst: maybe VK_FORMAT_A2R10G10B10 was faster on nvidia?
19:48jenatali: Fine, then check format support and use it if it's there, don't just assume that it is
19:48karolherbst: heh.. using different formats per GPU in a benchmark? that ain't fair :P
19:48neko2: when did nvidia ever play fair...
19:48neko2: *ducks*
19:49jenatali: Then... use the one that's guaranteed to be there
19:49neko2: ok, I'm not seeing any results thus far that have my particular looping crash issue. so I think it's safe to say I can file a new bug report there.
19:49karolherbst: you could submit patches and see what they say :D
19:50jenatali: Is that an OSS benchmark? I didn't think it was
19:50karolherbst: I mean.. you probably have access to the source, no?
19:51jenatali: Eh some groups at MSFT do, I don't
19:52karolherbst: heh
19:52neko2: karolherbst: btw, asssuming the specific trigger (whatever the heck libreoffice is doing) is never asked for in fixing the crash loop, what would then be the steps to go through to fix the bug with libreoffice's whatever-it's-doing causing a crash to begin with? I presume I'd need API traces or such
19:52karolherbst: but I suspect they'll say no "because that would make older results invalid"
19:52neko2: (and I imagine that'd be more the mesa side in terms of not sending something that'd crash to the gpu when given dubious input)
19:52karolherbst: neko2: probably?
19:53karolherbst: yeah soo there are always different pov here
19:53karolherbst: you could also argue that libreoffice might use the API incorrectly (if that's the case)
19:53neko2: oh, so it's not clear who's fault it is yet
19:53karolherbst: but regardless of that, mesa shouldn't really end up crashing the system
19:53karolherbst: and the kernel should be able to recover...
19:54karolherbst: but it also always depends on the things libreoffice is doing
19:54neko2: I personally think both sides should be corrected if possible tbh, especially if it runs on an older (stable?) kernel that has that bug
19:54karolherbst: some APIs specify that they can bring down the system if used incorrectly
19:54neko2: wait, I'm getting my layers confused now, nvm
19:54neko2: karolherbst: texture handles? x)
19:55neko2: (which I am told are sometimes just essentially GPU pointers)
19:55karolherbst: well.. anything where you hand in actual pointers can cause funky problems
19:55karolherbst: bindless_textures can be such thing in OpenGL e.g.
19:55neko2: right, bindless textures, that was what I was thinking of
19:56neko2: I am reminded of the confusingly named attrib pointer functions in openGL which were offsets, not actual pointers, despite the prototype... if I'm remembering that right anyway
19:57karolherbst: in any case, unprivileged Userspace shouldn't be able to bring down the system, because that's a CVE level bug
19:58neko2: yeah, there was already a joke in archlinux-offtopic on libera earlier, what a way to DoS an amdgpu system, send them a spreadsheet to open (or in fact anything that LO is set to open)
19:59neko2: all I was doing was trying to just view a spreadsheet I'd been sent. T_T alas s!@# happens
20:00neko2: anyway, thanks all for the input, it seems there's a clear order to at least get that reset bug fixed, then at least once I can trigger the crash without bringing the house down I can then do more useful debugging of whatever the heck libreoffice is doing.
20:02jenatali: And of course using ABGR instead of ARGB works just fine
20:14cmarcelo: jenatali: what's the minium required version of MSVC for Mesa?
20:15jenatali: cmarcelo: Either VS2019 or VS2022, not sure if we'd dropped 2019 yet
20:15jenatali: Any particular reason?
20:15jenatali: Ah CI still builds with 2019
20:17cmarcelo: jenatali: designated initializers... oldest clang / gcc we require support them even without C++20, I know "MSVC 2019 16.1" (is this what CI have?) does support it under /C++20. wondering if there's another flag for that in MSVC.
20:17jenatali: cmarcelo: No, it's only supported in C++20 mode
20:17cmarcelo: jenatali: context: https://gitlab.freedesktop.org/mesa/mesa/-/jobs/36599451 line 726
20:18jenatali: Build that test as C++20?
20:19cmarcelo: jenatali: would you be ok with "if msvc: set C++20"?
20:19jenatali: Yeah, fine by me
20:20jenatali: For that test at least, not sure if we want to upgrade the whole tree
20:20cmarcelo: sure
20:25jenatali: cmarcelo: Ping me in the MR if you want an ack from me on the patch :)
20:26cmarcelo: Cool tks.
21:03idr: jenatali: Does this look even close to correct: https://gitlab.freedesktop.org/idr/mesa/-/commit/8a3bb8f71b22fccb4f323e539e0ad758f9cff8fc
21:05jenatali: idr: Seems plausible. Where'd you find the 1930 number?
21:06idr: jenatali: https://stackoverflow.com/questions/70013/how-to-detect-if-im-compiling-code-with-a-particular-visual-studio-version
21:06idr: Other sources say 2019 needs /std:c++lastest while 2022 can use /stc:c++20.
21:07idr: Surely 38 random forum posts can't steer me wrong.
21:07cmarcelo: https://devblogs.microsoft.com/cppblog/msvc-cpp20-and-the-std-cpp20-switch/
21:07jenatali: Yeah I'm just not sure if that's the version number that meson detects
21:08jenatali: Lemme see what it says for my compiler
21:08cmarcelo: (shared just to note that: eventually even 2019 got the c++20 too, but not sure if is old enough)
21:10idr: 2019 16.11... but maybe not 16.9 or 16.10?
21:10jenatali: Yeah I think the first version number with support is 19.29
21:10jenatali: https://github.com/mesonbuild/meson/blob/master/mesonbuild/compilers/cpp.py#L735
21:11jenatali: That lines up with the output from the build job (https://gitlab.freedesktop.org/idr/mesa/-/jobs/36605312) saying the version number is 19.29.30146
21:12jenatali: _MSC_VER is a macro available in the source, which apparently has no relation to the version reported through stdout? I dunno it's all a mess
21:13jenatali: Oh I see, 1930 == 19.30, that makes sense. So yeah, < 19.29 instead of < 1930 is what you want
21:13idr: Yeah... I was just typing something like that. :)
21:15idr: Maybe "if 'c++20' in cc.get_options()" would be better?
21:15idr: dcbaker: ^^^
21:15idr: Or cpp_stds?
21:18dcbaker: idr: yeah, if you can`override_options : ['cpp_std=c++20']` or `=c++lastest` (meson should understand both), assuming a new enough version
21:19dcbaker: In famous words, I have some patches that I should finish up that would make that all more robust, but...
21:23idr:tries that...
21:27jenatali: Thanks. Sorry MSVC is a bit of a headache here :(
21:27demarchi: rodrigovivi: as we were talking earlier today, the subdir-ccflags in drivers/gpu/drm/xe/Makefile is applying the cflags to the whole dir instead of just to the display-related compilation units... do you know if there is a way to do one of the options below? 1) add a separate Makefile in the xe/display dir, so subdir-ccflags applies only to that, but still link everything in the xe.ko; or 2) replace the subdir-ccflags with something
21:27demarchi: else so it only applies to the display/%.o objects?
21:28jenatali: I wish it just supported designated initializers without having to be in C++20 mode
21:29dcbaker: I blame the C++ committee
21:31idr: dcbaker: Can you elaborate on "override_options"?
21:31idr: This did not work: https://gitlab.freedesktop.org/idr/mesa/-/commit/4753aa729b20165bf95c85baad154ab51505ca6c
21:31idr: https://gitlab.freedesktop.org/idr/mesa/-/jobs/36607114
21:33dcbaker: @idr, ah, `override_options` is a keyword to pass to a build target like `cpp_args`, but it tells meson "Hey, you know that default option I told you about? Yeah, ignore that, do this instead" so you'd write something like `cpp_std_override = ['cpp_std=c++latest']\n executable(..., override_options : cpp_std_override)`
21:33dcbaker: sorry, I should have been more clear about that
21:34dcbaker: which will stop meson from putting two c++ standard arguments into the command line
21:34dcbaker: src/intel/compiler does that with c++17
21:37idr: So... how do I do that to select between option A, option B, or nothing?
21:38idr: Because the "obvious" things don't work.
21:39idr: I might have a thing that's good enough...
21:40idr: https://gitlab.freedesktop.org/idr/mesa/-/commit/605d405a7e00f8c859e9f1e07ce6f9af5274dea4
21:40idr: That builds locally. :shrugh:
21:41jenatali: That looks reasonable to me
21:41idr: jenatali: We'll see if it also looks reasonable to the CI. :)
21:45rodrigovivi: demarchi: I really don't know... I believe that that separated file under the display dir could do the trick... the worst part that is the one I marked with XXX in the xe/Makefile I believe can be now removed after your patch to include the files directly or to remove the need for the i915 files...
21:49demarchi: # XXX: Needed for i915 register definitions. Will be removed after xe-regs
21:49demarchi: this?
21:49demarchi: this is a nop
21:50demarchi: the line above it will add the include to all .o
21:50demarchi: oh... you mean, if disabling display in the kconfig
21:53demarchi: rodrigovivi: no, we can't remove, unless we add more ifdefs around the code. I fixed several of those by removing display completely and checking the errors, but there are some hard ones:
21:54demarchi: drivers/gpu/drm/xe/xe_device_types.h -> display/intel_display_core.h -> the-world.h
21:55demarchi: and some files rely on this indirect include, like xe_pci.c
22:08rodrigovivi: ouch :(
22:09rodrigovivi: it would be good to have something cleaner for this display reuse...
22:45gfxstrand: Does anyone else remember this crazy loader bug where it falls over on vkGetPhysicalDeviceProperties2KHR() if you support gpdp2 but not 1.1?
22:45gfxstrand: Or maybe it's a crazy CTS bugb?
22:45jenatali: It's a CTS bug
22:46gfxstrand: Oh, so someone does remember it. :)
22:46jenatali: The CTS doesn't enable the extension for gpdp2
22:46gfxstrand: That'll do it
22:46jenatali: Yeah... I was tripping over it constantly until I flipped on 1.1
22:46gfxstrand: Ugh
22:46jenatali: I assumed it was a regression but according to the history for those tests, nope
22:46jenatali: And I didn't see any issues filed about it in a quick skim. I probably should've filed one
22:47gfxstrand: I'm guessing it wasn't a problem until Mesa started doing the right thing and returning NULL if you don't enable an extension
22:48jenatali: Yeah I'd believe that
22:48gfxstrand: alright, I'll see if I can fix the CTS quick.
22:48gfxstrand: I'd make my intern do that but I want her to still like me. (-:
22:50demarchi: rodrigovivi: for now I'm keeping a hack commit on top "Undo display", that at least lets me test if the rest is moving to the right direction
22:51demarchi: we may need to rethink the display integration
22:51demarchi: i.e. I know the way it is right now is temporary, but it shouldn't be causing issues to the rest of the driver
23:21gfxstrand: Ok, now that I figured out how to actually get SSH to work...
23:28Ristovski: I love it when I reboot and get a random beep code but I can't reproduce it anymore
23:29psykose: they should have replays but for Life
23:36Ristovski: hmm maybe there already is `irltrace`, and its being used to edit-and-replay Mike until he makes zink get 9000FPS in every benchmark possible
23:37zmike: sweatytowelguy.jpg
23:57gfxstrand: Why are these tests creating custom instances?!?