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