02:25 bl4ckb0ne: what's the difference between dri and gallium?
02:27 airlied: dri isn't very well defined
02:27 airlied: it means lots of things
02:27 airlied: gallium is an internal driver abstraction layer in mesa
02:28 bl4ckb0ne: i am working on a gles2 extension and i want to enable/build the minimum amount of thing (not a lot of power)
02:28 bl4ckb0ne: and in my config it complains that i have 2 i915 providers, dri and gallium
02:29 bl4ckb0ne: if i understand correctly, dri is for X server
02:29 airlied: okay in that case you just need to pick one i915 driver,
02:29 bl4ckb0ne: so since im on wayland, i should deactivate it and use gallium
02:29 airlied: you have an i915?
02:29 bl4ckb0ne: i915 is intel?
02:29 airlied: or i945? if not just disable both of them
02:30 airlied: it's old intel
02:30 bl4ckb0ne: i have a 2nd gen intel
02:30 bl4ckb0ne: i5 2520m
02:30 airlied: then you can just not build i915 at all
02:31 bl4ckb0ne: i965?
02:32 airlied: yeah just i965
02:32 bl4ckb0ne: and for gallium? i dont see i965 in the available options
02:32 airlied: nope
02:33 airlied: there i no gallium driver for that gpui
02:33 ascent12: Does iris only do relatively recent generations of intel?
02:33 bl4ckb0ne: so since im want to work on gles2, i can just completely disable gallium and dri?
02:34 airlied: ascent12: broadwell+
02:34 airlied: bl4ckb0ne: if you want to do anything with gles2 it needs a driver
02:34 airlied: and for you that driver isthe i965 dri driver
02:34 bl4ckb0ne: and no gallium
02:34 bl4ckb0ne: ?
02:34 ascent12: bl4ckb0ne: The dri here isn't reffering to the X extension.
02:35 airlied: bl4ckb0ne: indeed
02:35 airlied: no gallium at al
02:36 bl4ckb0ne: awesome thanks
02:36 bl4ckb0ne: configuration done
02:38 bl4ckb0ne: 21% battery left, might not be wise to start a build
07:03 danvet: ickle, do you need a backmerge for pushing the compile fix for the dma_addr_t lolz to drm-misc-fixes?
07:04 danvet: airlied, ^^ we seem to have lost that one
07:04 danvet: *drm-misc-next-fixes
07:04 danvet:not awake
07:06 danvet: hm backmerge is there
07:07 ickle: we are expecting someone else to apply it
07:07 ickle: +all
07:07 ickle: pick your favourite tree. do you have it checked it out?
07:08 ickle: or should I go ahead and push it?
07:08 airlied: danvet: doing another fixes tmrw
07:08 danvet: ickle, I asked you to push it to drm-misc-next-fixes
07:08 airlied: can you drop it in fixes?
07:08 danvet: airlied, yeah there's other stuff in drm-misc-next-fixes
07:08 danvet: so need a pull from that anyway
07:09 danvet: atm no maxime or maarten
07:09 danvet: tzimmermann, ^^ need a drm-misc-next-fixes pull in case your co-maintainers are awol already for the long w/e
07:11 danvet: ickle, anyway I pushed it now
07:11 danvet: hope you didn't fire up a tree already while my box here is compiling
07:11 danvet:not yet coffeed up maybe
07:15 airlied: would be good if we could have someone kick it in next 12 hrs
07:16 airlied: ill be doing some good friday roundups
07:17 danvet: tzimmermann, [PATCH] drm: Don't return 0 from a void drm_fbdev_generic_setup <- btw
07:30 LiquidAcid: hello, trying to debug a segfault with d3d9/nine, and i tracked it into iris; id_sha1 is 0x10 here:
07:30 LiquidAcid: https://gitlab.freedesktop.org/mesa/mesa/-/blob/20.0/src/gallium/drivers/iris/iris_disk_cache.c#L251
07:31 LiquidAcid: _mesa_sha1_format() then immediately faults
07:31 LiquidAcid: i'm currently rebuilding mesa with asserts enabled, but i wonder how this can happen
07:31 LiquidAcid: this is in a x86 (32bit) chroot, if that makes any difference
07:33 LiquidAcid: AHA!
07:33 LiquidAcid: triangle_SDL: ../mesa-20.0.2/src/gallium/drivers/iris/iris_disk_cache.c:249: iris_disk_cache_init: Assertion `note && build_id_length(note) == 20' failed.
07:34 LiquidAcid: (gdb) p note
07:34 LiquidAcid: $1 = (const struct build_id_note *) 0x0
07:48 tzimmermann: danvet, i think, i'll start next week. how urgent is it?
07:49 danvet: tzimmermann, mripard just joined, I think we're good
07:50 tzimmermann: danvet, i see
07:50 danvet: mripard, we need a drm-misc-next-fixes pull, in case maarten is already in the long w/e
07:50 danvet: so that airlied can forward the pile tomorrow .au time
08:00 mripard: danvet: yep, it was on my todo list for today
08:01 danvet: mripard, btw also noticed that there's a patch stuck in drm-misc-fixes it seems
08:18 zq: hi
08:18 zq: right place to ask development questions about aco?
08:19 dschuermann: sure
08:25 zq: so i noticed a cssa pass in the aco dir
08:26 zq: i've written one myself recently for llvm
08:27 zq: i'm still kind of new to aco_ir but do i understand correctly that the aco cssa inserts phi copies only where an interference is found?
08:27 zq: iiuc the boissinot paper advocates the opposite approach
08:28 dschuermann: well, that's the requirement for cssa...
08:29 zq: right, but the boissinot paper advocates inserting copies everywhere first and then coalescing wherever possible
08:29 zq: the aco approach looks a lot more like the sreedhar paper
08:29 zq: no criticism, just checking that my understanding is correct
08:30 dschuermann: we do ssa-based RA and coalesce the phi affinities directly during RA
08:30 dschuermann: the parallelcopies would need to transitively take care of that, so we don't really want them
08:31 dschuermann: we also only call the cssa pass if we need to spill. generally lowering to cssa has a negative impact on our code size
08:31 zq: oh interesting hm
08:32 zq: i haven't checked yet but do you split critical edges before cssa?
08:32 dschuermann: we don't create critical edges in the first place
08:38 zq: okay, i do see that bit in aco_validate
08:39 zq: is there a reason for this, and wouldn't it limit the classes of programs that can be compiled?
08:47 bnieuwenhuizen: It just means we have to maintain some basic blics with only a branch?
08:47 bnieuwenhuizen: blocs*
08:49 dschuermann: zq: the additional basic blocks get removed if they are not needed when transitioning out of ssa
08:49 dschuermann: you can transform every program in one without critical edges
08:49 pq: emersion, to retiterate, on some hardware, updating something on one CRTC necessarily requires updating something on another CRTC as well even though that other CRTC is not part of the atomic commit. So it has to be pulled into the atomic commit behind userspace's back, causing it to "glitch" a bit-
08:50 emersion: yeah, so nothing like "a big mode is being enabled here, the driver will steal an extra CRTC from user-space to be able to enable it"
08:51 emersion: i recall some driver wanted to do this for 8K or something?
08:52 danvet: emersion, oh we do that too
08:52 emersion: ahah :)
08:52 danvet: but for that cause we steal only what's available
08:52 danvet: which might result in a glitch
08:53 danvet: if e.g. such a big mode needs CRTC A & B
08:53 danvet: and atm you have B lit up already
08:53 danvet: so driver shuffles the current output on B to C
08:53 danvet: and A will actually be driven by A & B
08:53 danvet: but from userspace's pov it's all the same
08:53 danvet: minus the glitch
08:53 emersion: so, if after that user-space tries to use the stolen CRTC, all atomic commits will fail?
08:53 danvet: consensus is pretty much that if you need to steal resources (crtc or plane)
08:53 danvet: you need to fully virtualize them in the driver
08:54 danvet: emersion, no, exactly that's _not_ what happens
08:54 danvet: userspace still thinks it's driving crtc B
08:54 danvet: but it's remapped in the driver
08:54 danvet: same thing can happen with planes
08:54 emersion: okay, but initially if CRTCs A, B, and C are exposed
08:54 danvet: only thing userspace will observe is that you can't use all the crtc or all the planes
08:55 emersion: and the driver uses A & B for a single connector
08:55 emersion: what happens when user-space tries to use B?
08:55 danvet: driver will use C
08:55 danvet: if you then also try to enable C, then you get an -EINVAL
08:55 emersion: okay, failed atomic commit
08:55 danvet: and yes all drivers with big mode (whether on crtc or planes) work like that
08:55 emersion: cool
08:56 danvet: but the reshuffling required if you don't do a full modeset across all crtc (legacy userspace mostly, or just enabling another output)
08:56 danvet: might cause glitches
08:56 danvet: since driver needs to reassign the virtual->hw CRTC mapping
08:56 danvet: and other stuff that's shared underneath these
08:59 zq: dschuermann: for some instructions, it would be impossible to enter cssa without critical edges, fwiw
08:59 zq: boissinot talks about this
09:00 dschuermann: not sure I can follow... link?
09:00 dschuermann: does it refer to fixed-register branches and such?
09:01 zq: his exact example was single inst branch-and-decrement
09:02 zq: granted, this may not be a case that the amd backend needs to worry about for now
09:02 dschuermann: probably never ;)
09:02 zq: https://hal.inria.fr/inria-00349925v3
09:02 zq: figure 2
09:03 dschuermann: yeah, a branch which modifies a register becomes problematic
09:05 zq: "you can transform every program in one without critical edges" -- also, fwiw this is not true (:
09:06 dschuermann: ok, you got me there :P
09:14 dschuermann: doesn't POWER do such things? quite strange instruction for RISC °°
09:38 bnieuwenhuizen: zq: if you have a plain branch instruction you can. Just split the edge and add a basic block with an unconditional branch ?
09:38 bnieuwenhuizen: the new edges are not critical because the new BB only has 1 in-edge and 1 out-edge
09:55 LiquidAcid: i just opened a mesa pull request, but i've just realized that the patch is also a candidate for the stable branches -- is that something that should've been mentioned in the PR?
09:58 Venemo: LiquidAcid: you need to add a Cc tag to your commit message
09:58 Venemo: like this: CC: <mesa-stable@lists.freedesktop.org>
10:03 LiquidAcid: thanks, need to check which branches it applies to
10:11 MrCooper: can also reference another commit with "Fixes: <commit hash & shortlog>"
10:12 MrCooper: or in the worst case, can always create another MR for staging/20.0 once it's on master
10:14 LiquidAcid: MrCooper, good idea, also gives me some time to check which branches are affected
10:15 LiquidAcid: MrCooper, what does the guide (https://www.mesa3d.org/submittingpatches.html) understand by "active branches"?
10:15 LiquidAcid: that probably 20.0 and 19.0?
10:16 MrCooper: LiquidAcid: the Fixes: reference is enough to automatically determine if/where it needs to be backported
10:17 MrCooper: LiquidAcid: note that currently 20.0 is the only active stable branch
10:17 LiquidAcid: MrCooper, well, that's the problem, i never a bugreport for this, and i also couldn't say which commit this fixes
10:18 LiquidAcid: it's a shader cache issue, but does that automatically make the commit that introduced the shader cache to iris the culprit?
10:18 Venemo: if you don't know which commit it fixes, then a CC tag is enough
10:19 MrCooper: it's not really about "culprit"
10:20 MrCooper: just a reference to a commit which needs to be there for the fix to apply
10:22 emersion: is there a way to trigger drm_kms_helper_hotplug_event from user-space?
10:22 emersion: with a debugfs interface or similar?
10:23 LiquidAcid: MrCooper, well then, let's try this again
11:34 danvet: MrCooper, does nowc not affected testdmaperf?
11:35 danvet: seem to be getting exactly same numbers on my system here
11:54 emersion: replying to my own question: echo "detect" > /sys/class/drm/<vga card name>/status
11:54 MrCooper: danvet: testdmaperf always tests non-WC GTT
11:55 MrCooper: I think
11:55 danvet: I guess I'll crawl through more layers and see what's on then
11:57 MrCooper: without RADEON_FLAG_GTT_WC / AMDGPU_GEM_CREATE_CPU_GTT_USWC GTT is snooped
13:51 danvet: emersion, pq, ascent12 apologies if you've discussed this already on the new modifier hints proto, I didn't find that exact thing in all the comments in there
13:51 emersion: thanks for commenting!
13:52 emersion: so hmm
13:52 danvet: just came up, and I think we should make sure we have a consistent approach between the modifiers we assign in the kernel's drm_fourcc.h and what userspace compositor proto people want
13:52 emersion: if scan-out is possible, we want the client to allocate on the scan-out device
13:53 emersion: but we also want to be able to fallback to composition on the render device at any time
13:53 emersion: in case an atomic test-only commit fails
13:54 emersion: magic hidden memory could cause issues
13:55 danvet: emersion, yeah it's nasty
13:55 danvet: I think in practice we can always make sure that the client gives you something that you can both scan out and composite
13:55 danvet: maybe occasionally it would be good to optimize for composition only
13:56 danvet: not sure whether the hints should be a triplet for this
13:56 danvet: (dev, fourcc, modifier)
13:56 danvet: might be overkill, but not sure
13:57 emersion: but again, whioch device is "dev"?
13:57 emersion: which*
13:57 danvet: there's a bunch of examples from differents gpus and socs (from biggest to smallest gpu) where limitations happen
13:57 emersion: the render device or the scan-out device?
13:57 emersion: (or both?)
13:58 danvet: maybe both
13:58 danvet: e.g. if you have 2 nvidia cards with that hidden hiz
13:58 danvet: both can render, both can scan out
13:58 emersion: aye
13:58 danvet: but if you get a compressed thingy, you need to make sure the compositor agrees on which device it imports it on
13:59 danvet: there might be (even in practice) some silly soc system where you can scan out something
13:59 danvet: but not render with the gpu
14:00 danvet: but only use it with libva or some v4l device
14:00 danvet: (atm not much modifier support in either I think)
14:00 emersion: yeah i was thinking about that too
14:02 danvet: the other one which I expect to happen is content protection/encryption
14:02 danvet: where again you might not be able to use it with the gpu at all
14:03 danvet: gpu = the opengl/vk thing
14:03 danvet: jekstrand, ^^ fyi forgot to ping you
14:04 pq: danvet, no prob, the more the merrier. I actually shouldn't be touching the topic at all atm.
14:04 danvet: pq, did you comment on the recent modifier discussion too?
14:05 emersion: where did that discussion happen?
14:05 danvet: iirc some new drm soc display driver modifiers
14:05 emersion: hm, i just filter out driver-specific stuff
14:06 danvet: [PATCH v4 7/8] drm/fourcc: amlogic: Add modifier definitions for the Scatter layout
14:07 pq: danvet, oh yes, I have been testing the nerves of that person trying to get the AmLogic modifiers in.
14:07 danvet: emersion, added link to github
14:07 emersion: oh, *that* one
14:08 danvet: emersion, someone is going to do something like this, but then not connect all gpus/media devices to the same compression buffer I'm sure
14:08 danvet: fairly easy with lots of pcie cards actually
14:09 emersion: fun fun fun
14:10 danvet: the added fun is that sometimes you can still share these, if there's a fancy enough interconnect (on a soc, or one of these wobbly cables, or multi-gpu card)
14:10 danvet: and sometimes not
14:10 danvet: so a simple "this is an unshareable modifier" flag wont cut it
14:10 pq: the Wayland dmabuf protocol extension has support for graceful import failures, but people don't want to use it...
14:11 emersion: they prefer being disconnected with a protocol error
14:11 pq: "we know what works in advance anyway, why the roundtrip"
14:11 danvet: pq, yeah that part we need, but the hints also need to be up to it
14:11 pq: yeah
14:12 danvet: or we end up rendering into wrong buffers, and I think with vk you can't do magic underneath
14:12 danvet: or not much
14:14 pq: ah, vk - I'm still completely oblivious about it
14:17 pq: danvet, FYI, https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/298 is some weston-specific for protected buffers.
14:20 jekstrand: hakzsam: You're making me scared to work on spirv_to_nir! :-P
14:20 hakzsam: sorry :)
14:22 hakzsam: as discussed few days ago, we just want to be more careful about any spirv/nir changes to avoid situations like the recent reverts
14:23 hakzsam: RADV CI could solve a bunch of problems, but sadly it's still not ready :(
14:25 jekstrand: hakzsam: Yeah. I've got some stuff on my pipeline cache but it's pretty small and takes forever to run. :-(
14:25 jekstrand: I think the runtime could probably be improved if I took some time making ANV's pipeline cache better
14:26 jekstrand: For something like this vector insert thing, I don't know that it would have found it.
14:26 jekstrand: hakzsam: Can you tell me what apps those regressions were in?
14:27 hakzsam: jekstrand: btw, you can also test your spirv/nir changes against RADV (LLVM or ACO) with RADV_FORCE_FAMILY and vkpipeline-db
14:27 hakzsam: IIRC, id tech games, RotTR and probably more
14:27 jekstrand: Oh, I've got RoTR
14:27 jekstrand: I'll give it a try
14:29 hakzsam: jekstrand: https://hastebin.com/raw/iwitulawux
14:30 jekstrand: Oh, RotTR is helped :)
14:31 hakzsam: yes, apparently a bit :)
14:33 jekstrand:runs the rottr fossil
14:38 austriancoder: some gitlab ci specialist around? I am having troubles to get "extends"-container do the thing I want
14:39 austriancoder: my example: https://hastebin.com/owaqafofeq.makefile
14:39 austriancoder: ahh.. I think I know whats wrong
15:07 jekstrand: hakzsam: Where are we at on the CFG rework?
15:07 jekstrand: hakzsam: We now have a bug filed which it closes. :-)
15:08 hakzsam: jekstrand: yes, I will try to investigate in the next few days about the remaining changes
15:08 jekstrand: hakzsam: I don't intend to CC stable on it, BTW. Not unless we find an app in the wild which it fixes.
15:10 hakzsam: yes, I don't think we should backport it
15:10 hakzsam: I will look tomorrow then :)
15:10 jekstrand: Yeah, all the bugs that it fixes are things that GLSLang does *not* generate AFAIK
15:11 jekstrand: But they're valid SPIR-V so as we get more things generating SPIR-V, we're more likely to hit it.
15:11 hakzsam: right
15:20 swick: danvet: regarding modifiers, can't we handle the GPU you have to allocate the buffer on just like any other constraints like pitch, alignment, etc?
15:21 swick: right now we don't handle any of that stuff in the dmabuf extension but we will have to anyway
15:24 danvet: swick, atm we handle all that stuff with the "everyone allocates the same way"
15:24 danvet: that works well enough for modifiers
15:24 danvet: well, untiled modifiers
15:24 danvet: all the alignment stuff is really only a problem for untiled
15:24 danvet: most modifiers have built-in sufficient requirements to make everyone happy
15:25 danvet: swick, so this handwave doesn't really solve the real world issue I think
15:28 swick: hu, maybe I don't get it. you said on the MR "Personally I don't think encoding that kind of stuff into modifiers is a great idea, we can't encode every random constraint for buffer sharing into modifiers imo"
15:30 swick: ah, okay, I think I get it. What I meant was that we probably should communicate all the constraints over the protocol, not in the modifier, and that the device would be just one of those constraints
15:31 pq: the liballocator project was trying to come up with a way to express and compute with all kinds of contraints...
15:37 jekstrand: hakzsam: Looks like my new vector insert isn't quite as constant-foldable as the other one. :-(
15:37 hakzsam: can't this be fixed in NIR?
15:38 jekstrand: hakzsam: Yeah, I can make it so it handles constants as a special case.
15:38 hakzsam: cool
15:38 jekstrand: hakzsam: It should constant-fold ok if you scalarize but that means optimizations happen in a different order. :-(
15:38 hakzsam: we have to re-order some pass?
15:39 danvet: 1h of screaming later I realize I somehow have a 32bit glxgears here
15:51 tango_: danvet: well, at least it wasn't a missing underscore after 3 days of debugging
16:32 danvet: MrCooper, https://paste.debian.net/1139364/ I needed this to not make it die in an assert with AMD_DEBUG=nowc
16:34 MrCooper: mareko, pepp: ^ (I haven't been a radeonsi developer in a while :)
17:14 anarsoul: does anyone know how to apitrace chromium? I tried "--no-sandbox --renderer-cmd-prefix='apitrace trace'" but it doesn't work
17:15 anarsoul: chromium fails to create surface on lima: "[1718:1718:0408/120621.644939:ERROR:skia_output_device_gl.cc(137)] Couldn't create surface: 0 4 0 32856 {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} 1920x1042"
17:16 anarsoul: apparently lima lacks some format support but I need to figure out what format it is
17:21 anholt:has had no luck tracing browsers, would just printf debug it :/
17:26 DrNick: 32856 is GL_RGBA8
17:26 anarsoul: DrNick: yeah, but lima supports RGBA8 format
17:27 imirkin: anarsoul: i've definitely done something like that
17:27 imirkin: let me check my notes
17:27 imirkin: anarsoul: exec chromium --no-sandbox --user-data-dir=/tmp/chrome-gpu-debug --gpu-launcher='apitrace trace'
17:28 imirkin: the user-data-dir is so that it doesn't interfere with my regular session
17:28 imirkin: another one i used was this:
17:28 anarsoul: thanks, let me try that
17:28 imirkin: exec chromium --no-sandbox --user-data-dir=/tmp/chrome-gpu-debug --gpu-launcher='xterm -title gpu-launcher -e gdb -ex run --args'
17:28 imirkin: (obviously for different purposes)
17:36 subkelvin: can anyone help me with some pthread exception errors in building mesa? :)
17:37 subkelvin: ls
17:37 subkelvin: tail .bash_his
17:37 subkelvin: rm .bash_his .bash_his
17:37 subkelvin: tail .bash_his
17:37 subkelvin: ls -la
17:37 subkelvin: byobu
17:38 subkelvin: ls ~/Pri
17:38 subkelvin: sorry
17:38 subkelvin: pkill weechat
17:39 LiquidAcid: MrCooper, thanks for the hints, first time doing a PR through gitlab
17:42 anarsoul: imirkin: guess what? I can't reproduce the issue when I run it with apitrace :\
17:45 subkelvin: is there any channel specific to mesa?
17:46 imirkin: anarsoul: is the issue a crash? then try the gdb thing
17:47 imirkin: or something else gdb-able
17:47 anarsoul: imirkin: no, it fails to create surface
17:47 imirkin: so add a breakpoint
17:47 anarsoul: "[1718:1718:0408/120621.644939:ERROR:skia_output_device_gl.cc(137)] Couldn't create surface: 0 4 0 32856 {primaries:BT709, transfer:IEC61966_2_1, matrix:RGB, range:FULL} 1920x1042"
17:47 imirkin: in the mesa thing that returns an error
17:47 anarsoul: I don't have debug build for chromium :\
17:47 imirkin: nah, in mesa
17:47 imirkin: to figure out why the surface create fails
17:48 anarsoul: yeah, I don't know what GL call it translates to
17:48 imirkin: eglCreateSurface & friends?
17:56 subkelvin: just to know, is anyone reading me? :)
17:56 onox: are you a book?
17:57 subkelvin: onox: maybe
17:58 anarsoul: darn, too many layers of abstraction
17:59 anarsoul: imirkin: I think it uses glx by default
18:02 imirkin: if it's a debug mesa build, i think some things also print more info when returning an error
18:02 imirkin: not sure
18:04 imirkin: anarsoul: you could also look in that skia_output_device_gl.cc and see what it's trying to do
18:04 anarsoul: imirkin: already did, too many layers of abstraction
18:04 imirkin: hehe
18:04 anarsoul: I'm not even sure where exactly it reaches GL
18:04 imirkin: heh SkSurface::MakeFromBackendRenderTarget
18:05 imirkin: ok
18:05 imirkin: so
18:05 imirkin: i clearly don't know this stuff in detail
18:05 imirkin: but fFBOID is printed as 0
18:06 imirkin: which is the winsys fb. the surrounding code makes it sound like it should be an actual fbo though.
18:06 imirkin: oh, but this is gles2? so no fbo's ... hmm.
18:06 anarsoul: imirkin: I'm not limiting it to gles2, so I'm not sure what it tries to use
18:07 imirkin: what else do you have?
18:07 imirkin: GL 1.5? :)
18:07 anarsoul: lima exposes GL2.1 as well (however it doesn't adhere to spec...)
18:07 imirkin: framebuffer_info.fFBOID = 0;
18:08 anarsoul: ?
18:08 imirkin: it does that right above. so i was wrong
18:08 imirkin: or ... there's more to it
18:09 imirkin: either way, yeah, no way i'll figure it out without a lot more investigation
18:14 anarsoul: fFormat is GL_RGBA8
18:14 imirkin: right
18:15 imirkin: DrNick said that earlier
18:15 anarsoul: right
18:18 imirkin: looks like it does a bunch of shenanigans with ... something
18:18 imirkin: like look at this EnsureBackbuffer() func:
18:18 imirkin: https://chromium.googlesource.com/chromium/src/+/HEAD/components/viz/service/display_embedder/gl_output_surface_offscreen.cc
18:18 imirkin: perhaps you're missing some kind of image import/export stuff?
18:19 anarsoul: like what?
18:20 imirkin: screen->resource_from_handle and resource_get_handle
18:20 imirkin: are those ... handled?
18:21 anarsoul: yes
18:22 imirkin: my guess would be that one of them is returning an error
18:22 imirkin: can you add some extra prints in there?
18:23 anarsoul: yeah, sure, let me try that
18:32 anarsoul: nope, it doesn't fail there
18:38 imirkin: o well
18:58 jekstrand: hakzsam: Something very fishy is going on with vector insert....
18:58 jekstrand: hakzsam: Still trying to figure out what
19:43 karolherbst: did somebody ban uis here?
19:43 karolherbst: and why?
19:47 HdkR: `uis was kicked from #dri-devel by MrCooper [fix your connection]`
19:48 HdkR: Disconnect + Reconnect every five minutes for about 10 hours
19:48 HdkR: according to my logs
21:30 dcbaker: hakzsam: I just updated the 20.0-staging branch, and I had to pull in a few extra patches from you to get some of your nomintations to apply, let me know if everything looks good please
21:35 jekstrand: hakzsam: It's opt_undef that's screwing us over. :-(
21:37 jekstrand: hakzsam: I'm going to rework the MR to fix the bug, have some nice improvements, and not regress anything.
22:01 karolherbst: HdkR: yeah, but that's just a kick
22:01 karolherbst: not a ban
22:01 HdkR: karolherbst: Ban happened right before that
22:01 HdkR: Didn't want to burn two lines
22:02 karolherbst: ehhh... there is just one thing I can say about a ban like this: fix your client if this annoys you
22:02 karolherbst: also.. remove the ban if it's about something as stupid as this
22:04 HdkR: Yea, it should have been a timed KO in worst case, just to ensure they were allowed to come back if someone forgot to unban
22:04 karolherbst: yes
22:04 HdkR: But I'm not an op to remove the ban :)
22:04 karolherbst: yeah, me neither
22:04 HdkR: `[+b *!*@95.165.156.213]` that one specifically