00:00 imirkin: yeah, passing in bad pointers is always a good way to cause fail
00:02 jenatali: Someone on our app compat team decided to try RuneScape and sure enough it crashes, I don't think it asks for robustness but it looks like it expects it anyway
00:02 imirkin: "it works on nvidia"
00:02 imirkin: therefore your driver is broken. applications don't have bugs. drivers have bugs.
00:02 imirkin: welcome to the wonderful world of GL
00:03 dcbaker: I'm pretty sure "it works on nvidia" needs a trigger warning, lol
00:04 jenatali: Yeah I'm certainly expecting this won't be the last time I see a bug like this come across my plate
00:05 jenatali: And as is customary with Windows... yeah applications don't have bugs, drivers or the OS have bugs
00:06 imirkin: ah no. on linux, OS doesn't have bugs.
00:06 imirkin: it has features :)
00:07 Chaekyung: it's got bugs, I've seen many kernel panics in my time
00:07 imirkin: it was a tongue-in-cheek comment
00:08 imirkin: bugs are everywhere of course
03:24 agrisis: is userland drm supposed to be in /usr/include/libdrm or /usr/include/drm?
03:25 imirkin: libdrm usually
03:26 imirkin: er, depends what you mean by 'userland drm'
03:26 imirkin: if you mean "libdrm's installed headers", then libdrm
03:26 agrisis: maybe it's ubuntu and debian that install to /usr/include/drm?
03:27 imirkin: well, that's where linux's drm user headers end up
03:27 agrisis: yeah I noticed that
03:27 imirkin: the two aren't mutually exclusive :)
03:27 imirkin: i have drm and libdrm
03:28 imirkin: but usually you just #include, and use pkg-config to add the appropriate dir for libdrm
03:28 imirkin: i.e. you wouldn't #include <libdrm/foo>
03:28 agrisis: yeah true
03:29 agrisis: really?
03:29 agrisis: I see lots of code that do prefix libdrm/
03:30 agrisis: also I have a question in terms of latency
03:30 agrisis: I have an app that displays graphics at 60fps, my particular driver has forced vsync
03:31 agrisis: so drmModeSetCrtc will block up to 16.6ms - Xms where X is the time my app takes per frame
03:31 agrisis: if I wanted to offload the drmModeSetCrtc to a separate thread, is there any standard advice on how to set things up?
03:32 imirkin: yeah, don't do that
03:32 imirkin: let me double-check but iirc setcrtc is a full modeset
03:32 imirkin: you definitely don't want that
03:32 agrisis: really?
03:32 imirkin: yea
03:33 imirkin: you want like drmModePageFlip or something
03:33 agrisis: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/oga_gfx.c#L626
03:33 agrisis: that's my code
03:33 agrisis: well certainly as it stands, if my app only takes ~5ms I never miss a frame
03:33 imirkin: so like ... see how you pass in the video mode?
03:34 agrisis: yeah
03:34 imirkin: why might you want to do that?
03:34 agrisis: I wasn't aware of another way
03:34 alyssa: dscharrer: Vectors ruin SSA-based RA :'(
03:34 imirkin: i suspect that the core figures out that it's actually a no-op change and doesn't do the full thing
03:34 imirkin: but it's not a good thing to rely on if you don't expect the mode to change
03:35 agrisis: mode as is resolution?
03:35 imirkin: yes
03:35 agrisis: we fix it at 480x320
03:35 imirkin: (/ timings / etc)
03:35 agrisis: well actually 320x480 then we rotate it
03:35 imirkin: even more reason not to expect it to change :)
03:36 agrisis: yeah so I'm thinking about making 2 buffers on the fast path
03:36 imirkin: and flip between them
03:36 imirkin: that's a pretty common thing to do
03:36 agrisis: then signalling a separate thread to call drmModeSetCrtc
03:36 imirkin: drmModePageFlip
03:36 agrisis: I just don't want to tie up the fast path
03:36 imirkin: some drivers support async modesetting
03:36 imirkin: so then there'd be no blocking at all
03:37 imirkin: but not all
03:37 imirkin: (and you might need to use atomic APIs to access that functionality)
03:37 agrisis: https://github.com/libretro/RetroArch/blob/master/gfx/drivers/drm_gfx.c
03:37 agrisis: someone else wrote that
03:37 agrisis: I think it uses atomics as you said
03:38 agrisis: you think that might be a more reasonable starting point?
03:38 imirkin: yeah, in drm_page_flip
03:38 imirkin: well
03:38 imirkin: i haven't reviewed the code
03:38 imirkin: but i think if you just change your drmModeSetCrtc to drmModePageFlip, you'll be good to go
03:39 agrisis: drmModePageFlip doesn't block?
03:39 imirkin: let's start over
03:39 imirkin: under no circumstances should you be calling drmModeSetCrtc in order to just update the fb
03:40 imirkin: i don't know if page flip will block -- it might if you try to flip too much
03:40 imirkin: but you should still be using page flip
03:40 imirkin: because set crtc is a full modeset and you never want that (except on start)
03:50 agrisis: let me try it
03:50 agrisis: (sorry was afk)
03:53 agrisis: trying it out now
03:54 agrisis: I'm unsure about flags
04:11 alyssa: dschuermann: was the intended recipient of "Vectors ruin SSA-based RA :'(" whoops
04:11 alyssa: Trying to understand how to accurately estimate register pressure if you need contiguous registers for things (such that fragmentation of the register file is possible)
10:20 doras:sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/JsczTsqgxOlbSTLLniQIuACq/message.txt >
10:43 MrCooper: doras: IRC users only saw "doras sent a long message: <matrix.org URL>", not sure how many will bother clicking it to read your message... might be better posting to the dri-devel mailing list
10:44 MrCooper: that said, for now might be best to keep using the non-atomic cursor ioctl
10:47 MrCooper: BTW, I think the same issue basically applies even without VRR: if a flip misses vblank, we probably want the cursor to move anyway
10:48 DrNick: between Matrix's terrible long message handling and Matrix's terrible fake message editing, I'm thinking that *@gateway/shell/matrix.org/* should be set +q
10:51 MrCooper: would Matrix users get notified their messages are going into a black hole?
10:52 HdkR: Oh, Matrix allows you to do message editing? Hows does that even appear to the IRC side?
10:52 doras: MrCooper: well, shoot.
10:52 doras: It started short ;)
10:53 MrCooper: HdkR: I think the message is repeated in IRC after each edit
10:54 DrNick: HdkR: a bunch of repeated messages
10:54 doras: I'll give you a short demo: this is the original message.
10:54 doras: * I'll give you a short demo: this is the edited message.
10:54 MrCooper: the GNOME channels on GIMPNet made some tweaks to avoid bad behaviour with Matrix users
10:54 DrNick: Matrix isn't Microsoft Comic Chat levels of bad, but it is Not Good
10:55 doras: I wouldn't say bad. ItIt's not 1-to-1 compatible with IRC.
10:55 MrCooper: I'd say mapping it to archaic IRC is problematic :)
10:55 doras: It's*
10:55 DrNick: it should disable the features that IRC doesn't support
10:56 DrNick: and follow the existing conventions that IRC clients use for overly long messages
10:59 doras: I agree that this would have been a better way to handle the incompatibility.
11:01 DrNick: anyway, my ire isn't directed at you and my +q proposal is only half-serious
11:06 HdkR: Interesting
13:29 daniels: FWIW GitLab is getting upgraded to 13.9.1 about now (meant to do it much earlier this morning but couldn't), please expect a few minutes of bumpiness
13:40 daniels: and we're back
14:26 alyssa: dschuermann: "In this case, the register allocator inserts shuffle code"
14:26 alyssa: I should have read the README for ACO 😅
14:31 alyssa: As usual the problem for Mali is extremely complex scheduling reqs
14:31 alyssa: which feed in directly to RA
14:31 alyssa: so RA cannot efficiently insert _any_ code
14:32 alyssa: Potentially the right fix is observing code will only be inserted for high pressure shaders (defined as requiring spilling / shuffles / remats at RA time), which is somewhat rare so it need not be completely optimal
14:33 alyssa: and we could have a post-RA sched to try to compact code
14:39 dschuermann: alyssa: if you find a way to easily determine the chromatic number of the interference graph without copies, I'll help you publish a paper :D
14:40 dschuermann: my thoughts on the issue: if you treat vectors just as a bunch of vec1s, you can find a coloring without copies in linear time due to the chordal property of the graphs
14:41 dschuermann: the issue is that your vectors might land in non-neighboring registers
14:41 dschuermann: you would now have to sort the colors in such way that all vectors have only neighboring registers
14:42 dschuermann: obvious: this doesn't always work
14:42 edman007_: Hrm, I'm trying to build mesa master...and I'm getting undefined symbols LLVMInitializeBPFTarget LLVMInitializeBPFTargetInfo and a few other LLVM things...
14:42 dschuermann: not so obvious: what and where is the optimal copy insertion points
14:45 dschuermann: alyssa: w.r.t. shuffle code: we use some linear scan (or tree scan). the worst case is that we have to re-assign all variables in the register file to make space (happens once in the whole CTS)
14:56 alyssa: dschuermann: "if you find a way to easily determine the chromatic number of the interference graph without copies, I'll help you publish a paper :D" touche haha
15:02 alyssa: If we ignore vec3 for a moment, and only have vec4/vec2/scalar, it's tractable by assigning in 3 passes
15:02 alyssa: First do only vec4, since everything is the same size, there can be no fragmentation (the case is equivalent to scalar)
15:03 alyssa: Then doing only vec2, there can also be no fragmentation, since either it's the same size (other vec2) or a hole from a freed vec4 (fitting exactly 2 vec2's, allocated aligned in either location)
15:03 alyssa: Then do the scalar rest for which fragmentation is impossible anyway.
15:04 alyssa: This also has the property of aligning everything to its size and preventing allocations from crossing vec4 boundaries, which might be desirable for some archs. Bifrost doesn't care.
15:05 alyssa: Although I'm.. not really convinced such an allocation strategy is actually optimal. And then vec3 (and vec5/6/7/8/9/10/11/12 if you like GL4 texturing) comes in...
15:07 alyssa: I really don't care all that much about academically 'optimal' allocation. I just want something that's no worse than the heuristic we use now, at dramatically less compile-time by exploiting SSA properties..
15:41 dschuermann: alyssa it's also missing something. after allocating vec4 and vec2, it might be impossible to find space for vec1 without copy
15:42 dschuermann: alyssa: https://pastebin.com/H35ZAuVT
16:06 alyssa: dschuermann: I'm having troubles understanding the pastebin
16:16 dschuermann: sorry, it's just the regfile after each instruction
16:16 dschuermann: you can try to find an assignment which works without copy
18:56 mattst88: karolherbst: any clue about https://bugs.gentoo.org/773049 ?
18:57 karolherbst: mattst88: we don't report 1.2
18:57 mattst88: thanks, what's what I figured. so the reporter is just confused
18:58 karolherbst: I am not even sure we are even 1.0 compliant :p
18:58 alyssa: have you tried ~turning it off and on again~ installing gentoo?
18:58 karolherbst: anyway, devices report support for images, so we really can't expose 1.2
18:58 karolherbst: and we need to fix feature enumeration anyway :/
18:58 karolherbst: it will be a bit messy
19:33 abergmeier: Maybe dumb question but am I the only one who tried v3dv on 64bit?
20:38 imirkin: karolherbst: well, maybe *should* be, but definitely don't :)
20:39 karolherbst: :D
20:39 karolherbst: yeah...
20:39 karolherbst: but it's not as bad as like 2 years ago
22:24 marex: imirkin: hi, I ran into kernel crash in nouveau, is that something you're still interested in ?
22:24 imirkin: marex: sure why not
22:26 marex: imirkin: here https://paste.debian.net/hidden/0ecf35a5/
22:26 marex: imirkin: idmittedly, I haven't found report of this yet
22:27 imirkin: karolherbst: --^
22:27 marex: imirkin: it could also be fixed already in next or something specific to whatever stuff ubuntu has in their kernel
22:28 marex: 01:00.0 VGA compatible controller: NVIDIA Corporation GT216GLM [Quadro FX 880M] (rev a2)
22:28 marex: that's the GPU
22:28 marex: i.e. archaic stuff
22:28 imirkin: 09:00.0 VGA compatible controller [0300]: NVIDIA Corporation NV5 [Riva TNT2 Model 64 / Model 64 Pro] [10de:002d] (rev 15)
22:28 imirkin: i know something about archaic.
22:28 marex: imirkin: brings back memories :)